2012-01-05 30 views
17

Trong khi refactoring mã Tôi đã thay đổi tất cả nếu không điều kiện null để làm theo quy ước đa số trong mã của tôi vềKhi sử dụng!() Hoặc! = Khi nếu không null

if (!(foo == null)) 

thay vì

if (foo != null) 

Có lợi thế nào trong tuyên bố không?

Có lợi thế nào trong câu lệnh trong C# không?

+0

Cảm ơn mọi người, có thể tái cấu trúc lại: -/ –

Trả lời

26

Tôi tìm thấy tệp thứ hai dễ đọc hơn.

Ngoài ra, không có sự khác biệt.

Điều quan trọng hơn là phải chọn một quy ước với nhóm của bạn và gắn bó với nó trong bất kỳ một codebase cụ thể nào.

+8

Dễ đọc hơn nhiều. –

+0

Và ngoài ra khi bạn đang đọc mã trong kịch bản đầu tiên bạn có thể thấy các hành động (bằng và không) nhưng trong phần thứ hai, nó "đọc thân thiện" hơn và bạn cảm thấy như hành động đơn lẻ. – Samich

+0

@Oded: Đồng ý "thứ hai (* hơi *) dễ đọc hơn" tương đối với câu hỏi đầu tiên, nhưng đó là IMHO, WAY không thể đọc được vì lý do và liên quan đến đề xuất thay thế trong Câu trả lời ngày 12/21/của tôi 17 bên dưới. Ngoài ra, thường là "quy ước", điều đó có thể hoàn toàn tốt đẹp dựa trên kiến ​​thức và tình huống vào thời điểm đó, hoàn toàn không đầy đủ trong ánh sáng kiến ​​thức và/hoặc tình huống mới. – Tom

10

Giả sử bạn không bị hỏng ==/!= tình trạng quá tải của nhà điều hành, tôi chỉ sử dụng biểu mẫu thứ hai vì lợi ích của tính đơn giản/dễ đọc. Nếu bạn do có quá tải bị hỏng sao cho có sự khác biệt ngữ nghĩa giữa hai trường hợp này, thì tôi khuyên bạn nên khắc phục những sự quá tải đó :)

Trong trường hợp hiếm hoi, nơi có thể chỉ định sử dụng biến cục bộ:

bool somethingIsMissing = foo == null; 
if (!somethingIsMissing) 
{ 
    ... 
} 

Dấu ngoặc tròn quanh foo == null hiện là tùy chọn - sử dụng hoặc không, theo khẩu vị. Điều chính là bạn có thể sử dụng tên biến để làm cho ý nghĩa ngữ nghĩa thực sự rõ ràng.

+0

IMHO, vẫn WAY quá không thể đọc được vì lý do và liên quan đến đề xuất thay thế trong Câu trả lời của tôi ngày 21/12/17 dưới đây. – Tom

+0

@Tom: Tôi nghĩ chúng tôi sẽ phải đồng ý không đồng ý. Tôi muốn sử dụng cách tiếp cận thông thường, thành ngữ sẽ không làm bất kỳ nhà phát triển nào ngạc nhiên. –

2

Theo ý kiến ​​của tôi, không có sự khác biệt, trình biên dịch sẽ tối ưu hóa mã. Nhưng tôi thích if(foo != null). Ít dấu ngoặc đơn và dễ đọc hơn.

5

thường if (!(foo == null)) được sử dụng khi bạn có các biến hơn để ân cần, ví dụ

if (!(f1 == 'a' && f2 != 'b')) 

đôi khi chỉ là dễ dàng hơn theo cách này rằng chuyển đổi tất cả mọi thứ để điều ngược lại, đặc biệt khi bạn sử dụng toán tử Bitwise.

+5

Tôi có thể sử dụng 'if (f1! = 'A' || f2 == 'b')' để rõ ràng hơn trong trường hợp đó. –

+0

thật khó khi bạn có một chuỗi lớn và đặc biệt với cờ: -/nó có thể đọc được nhiều hơn như 'if (! (E.Row.RowType == DataControlRowType.DataRow && (e.Row.RowState & DataControlRowState.Edit) = = DataControlRowState.Edit)) 'không?giống như 'nếu không phải là một loại DataRow hoặc Edit ...' – balexandre

+0

Đó là loại tình huống mà tôi có thể tách biệt điều kiện thành một biến cục bộ với một tên có ý nghĩa. –

5

Cách đầu tiên sử dụng hai toán tử, toán tử thứ hai sử dụng một toán tử. Vì vậy, kỹ thuật, thứ hai là đơn giản hơn.

+0

nhưng việc thực thi được đề xuất của toán tử ' ! = 'là' trả về! (a == b) '. Vì vậy, nó không dưới mui xe giống nhau. – Oliver

+1

Điều này giống như nói rằng một chiếc xe máy dễ lái hơn một chiếc xe hơi, bởi vì nó có ít bánh xe hơn. – Sjoerd

1

Ưa thích của tôi là cái thứ hai, vì nó dễ đọc hơn cái đầu tiên.

Chúng không có sự khác biệt vì vậy nó chỉ là vấn đề lựa chọn cho bạn.

Tuy nhiên, nếu bạn có nhiều biến khác trong mệnh đề if của bạn, thì đầu tiên có thể là biến được sử dụng.

Lựa chọn của bạn cuối cùng.

3

Nơi duy nhất nơi mà tôi sẽ sử dụng !(a == b) sẽ trong việc thực hiện điều hành của != như theo cách này:

public static bool operator != (MyType a, MyType b) 
{ 
    return !(a == b); 
} 
0

Kể từ, hình thức đầu tiên sử dụng 2 vs 1 C# Các nhà khai thác, nó thể biên dịch để hơn Mã CIL mặc dù, trong hầu hết các trường hợp sử dụng nhiều nhất sẽ gặp phải, nó có thể sẽ không làm cho một kích thước mã đáng kể hoặc hiệu suất khác biệt.

Điều gì có khả năng tạo sự khác biệt đáng kể là khả năng đọc và do đó có thể xảy ra lỗi khi viết/sửa đổi. Tôi sẽ (và bạn Sheldons có thể muốn che mắt của bạn bây giờ) tránh việc sử dụng "!" Nhà điều hành com-PLETELY. "Gasp! Của tôi - WORD!" Vâng, tôi đã nói. Và tôi nghĩ rằng nó! Với một PASSION! Nó quá dễ bỏ lỡ vì nó thường nằm bên cạnh một ký tự dấu chấm câu tương tự (ví dụ "(") ở bên trái và một chữ cái Định danh tương tự (ví dụ "I") ở bên phải. Và thiếu nó có thể có hậu quả chính, vì nó có nghĩa là bạn nghĩ rằng mã đang thực hiện OPPOSITE chính xác về những gì nó thực sự đang làm! Và nó cũng có thể bị bỏ sót nhiều hơn bởi các chứng khó đọc làm cho nó có khả năng là một vấn đề về quyền tàn tật được ADA bảo vệ. sau rất có thể ví dụ:

if (!IsIisServerConnected) 
    if (IsOfflineMode || !(IsIisLocalServerConnected || IsIisCloudServerConnected)) 

tôi sẽ thay vì viết như sau:

if (false.Equals(IsIisServerConnected)) 
    if 
    (
    IsOfflineMode 
    || false.Equals 
    (
     IsIisLocalServerConnected 
     || IsIisCloudServerConnected 
    ) 
    ) 

Hoặc trong trường hợp của bạn:

if (false.Equals(foo == null)) 

Hãy nhớ rằng C (ngôn ngữ C#, C++, JavaScript, Java và nhiều ngôn ngữ phổ biến hiện nay khác cuối cùng thừa hưởng cơ bản cú pháp của họ từ) được tạo ra tại một thời gian khi Thẻ Punch vẫn còn phổ biến. Với các CPU hiện đại, RAM, màn hình và IDE (đoạn mã "false.Equals (?)" Có thể được tạo bằng Shortcut Keyboard tùy chỉnh), với hầu hết mọi người cho hầu hết các ứng dụng, khả năng đọc là nhiều, nhiều, MUCH (tôi đã đề cập đến) nhiều "?) quan trọng hơn việc lưu một vài ký tự mã.

P.S. Bạn cũng có thể thêm Phương thức tiện ích vào số Boolean Cấu trúc gọi nó, oh, tôi không biết, Not! ; D Vì vậy, bạn có thể viết:

if (IsIisServerConnected.Not()) 
if ((foo == null).Not()) 
Các vấn đề liên quan