2009-08-20 23 views
13

Thực hành nào tốt hơn? (Tôi đang mã hóa trong Net nếu mà làm cho một sự khác biệt)Thực hành tốt nhất về Lệnh kê khai IF/ELSE

IF condition = true THEN 
    ...true action--even if rare... 
ELSE 
    ...action 
END IF 

hoặc

IF condition = [most common condition] THEN 
    ...most common action.... 
ELSE 
    ...least common action 
END IF 
+0

Câu hỏi của bạn không có ý nghĩa nhiều. Nó không rõ ràng những gì bạn đang yêu cầu. Ông có thể làm rõ? –

+0

Trong câu lệnh thứ hai, điều kiện khác sẽ không bao giờ được thực thi –

+1

Câu lệnh thứ hai có thể được diễn đạt tốt hơn "Nếu điều kiện = [điều kiện phổ biến nhất] THÌ" thay vì "đúng hay sai" - tôi hiểu những gì bạn đang cố nói, nhưng đó là một cách khó hiểu để cụm từ nó. – matthock

Trả lời

31

Theo Steve McConnell, tác giả của Code Complete, bạn nên

"Put the case you normally expect to process first. This is in line with the general principle of putting code that results from a decision as close as possible to the decision...[putting the normal case after the if] puts the focus on reading the main flow rather than on wading through the exceptional cases, so the code is easier to read overall."

Code Complete , 2nd Edition, các trang 356-357.

+1

Tôi có xu hướng đồng ý, nhưng đôi khi bạn có thể có mức độ lồng nhau của các trường hợp ngoại lệ thì khó để xác định cái nào sau khi hoàn thành trường hợp bình thường. đôi khi thật tuyệt khi thấy các ngoại lệ này đến cái khác và nếu bạn đã xoay xở để rơi xuống đáy, bạn biết rằng bất cứ thứ gì bạn đang xử lý đều bình thường. –

+1

Ty W, đó cũng là cách bạn làm cho chương trình thực hiện kiểm tra không cần thiết hầu hết thời gian. – Breakthrough

+2

+1 để tham khảo * Mã hoàn thành *. – Imagist

7

Go với các phiên bản có thể đọc được hầu hết các trường hợp cụ thể của bạn, và bằng cách này, đừng so sánh biểu thức boolean thành true và false. Sử dụng conditionNot condition (!condition trong C#.)

if (condition == true) // bad 
if (condition) // better 
+0

Chỉ tò mò, nhưng tại sao nếu (điều kiện == đúng) được coi là xấu? Quá dài dòng? – Jeff

+4

Đầu tiên, nó chỉ làm xáo trộn mã. Bạn càng viết ít, bạn sẽ càng ít phải đọc và hiểu. Ngoài ra, có khả năng bạn bỏ lỡ một dấu bằng và nó sẽ trở thành 'if (condition = true)' mà không phải là những gì bạn muốn. (May mắn thay, trình biên dịch C# sẽ đưa ra cảnh báo, nhưng tại sao không ngăn chặn nó ngay từ đầu?) –

+3

thực hành cá nhân của tôi là làm điều kiện (điều kiện) để đánh giá đúng, và nếu (điều kiện == sai) để đánh giá sai. Tôi thấy nó quá dễ bỏ lỡ nếu (! Điều kiện), cộng với cá nhân tôi nghĩ rằng nó đọc tốt hơn "nếu không điều kiện" và "nếu điều kiện là sai" – Matt

1

Sử dụng bất cứ làm cho mã dễ đọc hơn. Đây thường là tùy chọn thứ hai của bạn.

Sửa

Trong nhiều trường hợp, nó phụ thuộc vào những gì bạn đang cố gắng để đạt được, ví dụ, nếu bạn muốn kiểm tra xem kết nối bắt đầu một cách chính xác:

Connect() 
if connected then 
    SendString("Hello!") 
else 
    FlagConnectionFailed() 
endif 

Trong khi nếu bạn muốn bắt một lỗi:

' Just about to send something 
if not connected then 
    FlagConnectionLost() 
    return 
endif 
SendString("Still connected!") 

Nhưng thậm chí bạn có thể muốn:

Disconnect() 
if not connected then 
    return "Complete" 
else 
    FlagConnectionDisconnectFailure() 
endif 

(Tôi không phải là một lập trình viên VB, vì vậy cú pháp trên chủ yếu tạo thành!)

3

Trước hết, bạn không nên so sánh với các giá trị boolean, đây là, làm

if condition then 

thay vì

if condition = true then 

Về câu hỏi của bạn, nó phụ thuộc vào tên biến tự nhiên, IMO .

Ví dụ, nếu bạn đang tạo một khách hàng mà cần phải kiểm tra xem nó được kết nối (trường hợp phổ biến nhất)

if connected then 
    //Proceed 
else 
    //Throw error 
end if 

Hoặc, nếu bạn đang tạo ra một chương trình khác nhau, nơi bạn có một biến, nói , lấy ra và bạn muốn biết nếu nội dung đã được lấy ra

if not retrieved then 
    //Error 
end if 

Đừng làm

if retrieved then 
else 
    //Error 
end if 
1

Như những người khác đã nói khả năng đọc nói chung là quan trọng hơn. Tuy nhiên, khả năng đọc có nghĩa là những thứ khác nhau với những người khác nhau.

Đối với tôi, điều này thường có nghĩa là sắp xếp câu lệnh if để hành động ngắn hơn (về dòng mã) xuất hiện trước, để nếu câu lệnh ở gần cuối cửa sổ, tôi có nhiều khả năng xem "Khác" trên màn hình.

Đối với những người khác, đặt "Không" trong điều kiện thực sự có thể ném chúng, và vì vậy, họ muốn liệt kê nó để điều kiện Nếu điều kiện luôn tích cực nhất có thể.

2

Nói chung, tôi luôn đặt mệnh đề đúng trước. Một cái gì đó như thế này, đối với tôi, hoang mang ý nghĩa:

If not something Then 
    'do something 1 
Else 
    'do something 2 
End If 

Điều này dẫn đến một đôi tiêu cực, tốt hơn nhiều để viết nó như thế này:

If something Then 
    'do something 2 
Else 
    'do something 1 
End If 

Tôi tin rằng đề nghị này xuất phát từ mã hoàn chỉnh. Một cuốn sách tuyệt vời rất đáng đọc

http://www.cc2e.com/

Nếu bạn đang đi để có nhiều hơn một người khác sau đó nó có thể là tốt hơn để xem xét một tuyên bố như vậy.

1

Phương pháp hay hơn là tùy chọn thứ hai - hành động phổ biến nhất trước tiên.

Giúp bạn dễ dàng đọc mã khi bạn không bị phân tâm bởi mã cho trường hợp ít được sử dụng/ngoại lệ hơn.

3

Trong mã lắp ráp/máy cuối cùng, nó tạo sự khác biệt. Câu lệnh có nhiều khả năng được thực thi nhất được thực hiện trong đường dẫn mà không có nhánh. Bằng cách này, các đường ống không bị hỏng gây ra chu kỳ có giá trị bị mất.

Tôi không có đầu mối nào nếu trình biên dịch rời khỏi lệnh nếu lệnh sau đó của bạn còn nguyên vẹn và cách này buộc lắp ráp thực hiện tuyến đường tối ưu này.

Tôi đã đọc rằng studio hình ảnh 2008 (khi được thông báo) sẽ có chức năng tối ưu hóa, nơi trình biên dịch thêm phép đo tại các nhánh và sau đó trong thời gian chạy đo tần suất một đường dẫn certian được thực hiện. Sau đó, trong các lần biên dịch tiếp theo, đường dẫn mã tối ưu nhất được ưu tiên.

tôi không có đầu mối nếu tính năng này bao giờ thực hiện nó quá khứ 'thiết kế/giai đoạn học tập'

+1

@reinier Tối ưu hóa thời gian biên dịch này được thực hiện trong trình biên dịch HotSpot cho Java. Tôi đoán là điều này dẫn đến việc nó cũng đang được triển khai trong .NET vì Microsoft đang chịu nhiều áp lực để theo kịp với Jones. – Imagist

+1

Việc tối ưu hóa tôi đang nói về thực sự là về mức mã máy (Đối với trình biên dịch C). Vì vậy, không có tối ưu hóa bytecode cho .net và java giống như các chương trình. – Toad

1

Nếu trường hợp phổ biến nhất không phải là đơn giản nhất để thể hiện, bạn có thể có một cơ hội để tái Sacombank

Một hữu ích tái bao thanh toán tôi đã tìm thấy:

if (a.getFoo() == 1 && a.getBar() == 2) 

có thể được tái yếu tố để

if (a.isFooBar()) 
.210

Trong trường hợp đi một cái gì đó khó chịu như thế này,

if (!(fooSet.contains(a.getValidFoo()))) 

có thể

if (a.hasInvalidFoo(fooSet)) 

này có thể làm cho phương án 1 cũng có phương án 2 bởi đơn giản hóa việc đánh giá tình trạng phổ biến nhất.

2

Bạn đã nhận được một số câu trả lời khá hay. Tôi sẽ tiếp cận câu hỏi từ một góc độ khác.

Đầu tiên, theo như hiệu suất, nó có thể không quan trọng nhiều như bạn nghĩ trong các CPU hiện đại. Đó là bởi vì họ sử dụng một tính năng được gọi là dự đoán nhánh trong đó CPU cố gắng dự đoán hướng có khả năng nhất mà mã sẽ thực hiện. Tất nhiên, tôi vẫn đồng ý rằng bạn nên đặt chi nhánh có khả năng nhất ở đầu nếu hiệu suất là mối quan tâm chính của bạn.

Thứ hai, tôi thích khả năng đọc hơn các cải tiến hiệu suất tầm thường. Trong hầu hết các trường hợp, lợi ích của khả năng đọc vượt trội so với hiệu suất.

Thứ ba, sử dụng guard clauses khi có thể. Nó làm cho mã dễ đọc hơn.

Các vấn đề liên quan