Tại sao một số lập trình viên có kinh nghiệm viết so sánh với giá trị trước biến?

Question

Possible Duplicates:
How to check for equals? (0 == i) or (i == 0)
Why does one often see “null != variable” instead of “variable != null” in C#?

Tôi đã có một cái nhìn tại một hướng dẫn kỳ lạ ở đây và ở đó cũng như một số mã DirectX và nhận thấy rằng nhiều lập trình viên có kinh nghiệm C++ viết các biểu thức theo cách sau:

(<constant> == <variable>) 

hơn những gì trí tuệ thông thường của tôi có vẻ thích:

(<variable> == <constant>) 

Ví dụ: if (NULL == ptr) thay vì if (ptr == NULL). Tôi thích sự thay thế thứ hai, nếu không có lý do khác để lựa chọn trước đây, lý do của tôi là biến có vẻ là "nhận" kết thúc của biểu thức.

Nhưng tôi nghi ngờ tên cũ được sử dụng để tránh vô tình gán giá trị của hằng số cho biến bằng cách sử dụng = thay vì ==. Điều đó có đúng không?

Answer 1

Vâng, đúng vậy. Đó là để phát hiện lỗi đánh máy của = thay vì ==.

Answer 2

Nó tránh được rằng bạn viết var = NULL. Viết NULL = var sẽ sinh ra lỗi. Vì vậy, bạn đúng :-)

Answer 3

của nó bởi vì bạn không thể gán một giá trị cho một hằng số, vì vậy nếu do nhầm lẫn bạn đặt = thay vì == trình biên dịch ném một lỗi, cảnh báo cho bạn

Answer 4

Đó từng là trường hợp, vâng. Tất nhiên, ngày nay hầu như tất cả các trình biên dịch cảnh báo về các bài tập trong điều kiện if(), do đó, lợi thế chỉ dành cho những người thường xuyên ngăn chặn cảnh báo.

Answer 5

Đó là lý do phổ biến, cũng như đối số mà bạn không muốn đẩy hằng số ra phía xa bên phải của màn hình với biểu thức dài dòng. Đối số thứ hai chưa bao giờ có vẻ thuyết phục với tôi, và cái cũ không thực sự hợp lệ trong những ngày này, vì bất kỳ trình biên dịch tự tôn trọng nào cũng sẽ đưa ra cảnh báo (bạn biên dịch với cảnh báo-như-lỗi, phải không ?--) .

EDIT: Tôi vừa xem qua bản xem trước Xcode 4 mới và chỉ xem ví dụ mà họ đã chọn để minh họa cho tính năng "Khắc phục sự cố" mới của họ!

alt text http://devimages.apple.com/technologies/tools/images/new_autocorrect20100721.jpg

Answer 6

Để nắm bắt sự khác biệt giữa việc chỉ định và so sánh.

Nếu bạn muốn tìm:

if (ptr == foo) 

nhưng gõ

if (ptr = foo) 

nếu vẫn sẽ là mã hợp lệ, vì ptr = foo sẽ đánh giá để kiểm tra boolean trên ptr sau khi nó đã được thiết lập với giá trị của foo. Rõ ràng, bạn không muốn điều này.

Tuy nhiên, tôi thấy nó gây tổn hại đến khả năng đọc đáng kể, và cho rằng hầu hết các IDE và tiền xử lý sẽ bắt được điều này, không bao giờ sử dụng kiểu này.

Answer 7

Là một nhà phát triển java Tôi có xu hướng viết các biểu thức như thế này:

//primitive check 
    if(constant == variable) 

    //Object check 
    if(constant.equals(variable)) 

Điều này đặc biệt quan trọng đối với các đối tượng vì biểu thức không làm lỗi nếu biến là null. Nếu biểu thức được theo thứ tự khác, một biến null sẽ bị lỗi. Tôi duy trì tính nhất quán và làm theo thứ tự cho các nguyên thủy.

Answer 8

Kiểm tra ra câu trả lời hàng đầu đánh giá cho câu hỏi này ..

https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

Họ đã đặt tên này phong cách mã hóa "Yoda điều kiện".

Answer 9

Điều này đã được gọi là "Điều kiện Yoda"!

Xem ở đây https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

Tôi thực sự thích rằng hạn vì:

if(Light::On == light) 

Reads như:

"If on is the light"

Như đã trình bày rồi, này được sử dụng để ngăn chặn chuyển nhượng không chính xác. Nó có thể được lập luận rằng thực hành này là cổ xưa dựa trên IDE hiện đại nhưng tôi vẫn nghĩ rằng đó là thực hành tốt.

Answer 10

Ghi nhận nhiệm vụ là lý do chính Các điều kiện Yoda được sử dụng, nhưng có những điều khác: Trong C++ toán tử được gọi trên toán hạng LHS. Vì các hằng số thường là const (duh) hoặc nguyên thủy, điều này hạn chế khả năng hoạt động không có tính nhạy cảm. Một ví dụ là = trên nguyên thủy, chẳng hạn như lý do phổ biến nhất định (1 = a), nhưng điều này sẽ bao gồm operator=() const hoặc bất kỳ toán tử nào được sử dụng cho các loại không phải POD.

Answer 11

Với một ngôn ngữ như VB 6.0 mà không không có phân biệt và toán tử so sánh,

a = 2

'sẽ biên dịch, cho dù bạn có nghĩa là một được gán 2 hoặc cho dù bạn đang so sánh một với 2 Nếu bạn có nghĩa là so sánh, có khả năng xảy ra lỗi thời gian chạy.

'Đối với chuyển nhượng nếu bạn luôn viết

a = 2

' Và đối với chuyển nhượng nếu bạn luôn viết

2 = a

'Bạn loại bỏ Compile-thành công và thời gian chạy kịch bản.

Nhưng, đây chỉ là mẹo: gợi ý trực quan không khả dụng khi bạn có biểu thức như

a = b 'So sánh hoặc gán?

C# có: - gán khác (=) & so sánh (==) ký hiệu - so sánh phải được bao bọc trong ngoặc đơn.

Sau đó, điều này sẽ không thành vấn đề.

Answer 12

Bởi vì họ biết những gì họ đang thực hiện: P

Answer 13

Bạn nói đúng - đó là để kích hoạt một lỗi biên dịch nếu bạn nhập nhầm "==" là "=", kể từ khi chuyển nhượng sẽ luôn luôn trở thành sự thật. Trong khi điều này thường sẽ dễ dàng nhận thấy và gỡ lỗi, một lần trong một thời gian nó sẽ biến thành một rất khó để phát hiện lỗi, nghĩ về điều này:

#define OK 2 // Or something... 
[...] 
while(status = OK){ 
    // This loop will never end 
    // Even if you change the value of status within it 
    [...] 
} 

Đó có thể là một lỗi khó chịu để tìm kiếm, đặc biệt là nếu khối thuộc về tuyên bố vi phạm là dài (hãy tưởng tượng tìm kiếm tất cả các lý do có thể có tại sao trạng thái luôn ở trạng thái OK).

Nếu mặt khác bạn sử dụng:

while(OK = status){ 

Điều đó sẽ ném một lỗi biên dịch, vì bạn không thể gán một giá trị cho một hằng số.

Thực hành này đôi khi được gọi là điều kiện Yoda, vì nó juxtaposes đối tượng và chủ đề. Giống như "nếu trạng thái là OK" so với "nếu OK là trạng thái" và "bầu trời có màu xanh" so với "màu xanh dương là bầu trời" - thứ hai là thứ mà Yoda có thể nói.