object == null hay null == object?

Tôi đã nghe ai đó nói rằng null == objecttốt hơn là object == null kiểm tra

ví dụ :

void m1(Object obj ) {
   if(null == obj)  // Is this better than object == null ? Why ?
       return ;
   // Else blah blah
}

Có lý do nào không hay đây là một huyền thoại khác? Cảm ơn vì sự giúp đỡ.

Đây có lẽ là một thói quen học được từ C, để tránh loại lỗi đánh máy này (đơn =thay vì kép ==):

if (object = null) {

Quy ước đặt hằng số ở bên trái ==không thực sự hữu ích trong Java vì Java yêu cầu biểu thức trong một ifđánh giá thành một booleangiá trị, vì vậy trừ khi hằng số là a boolean, bạn sẽ gặp lỗi biên dịch theo cách bạn đặt tranh luận. (và nếu nó là boolean, bạn vẫn không nên sử dụng ==...)

Như những người khác đã nói, đó là một thói quen học được từ C để tránh lỗi chính tả - mặc dù ngay cả trong C, tôi vẫn mong đợi các trình biên dịch tốt ở mức cảnh báo đủ cao để đưa ra cảnh báo. Như Chandru nói, so sánh với null trong Java theo cách này sẽ chỉ gây ra vấn đề nếu bạn đang sử dụng một biến kiểu Boolean(mà bạn không có trong mã mẫu). Tôi muốn nói rằng đó là một tình huống khá hiếm gặp và không phải là tình huống đáng để thay đổi cách bạn viết mã ở mọi nơi khác. (Tôi sẽ không bận tâm đến việc đảo ngược các toán hạng ngay cả trong trường hợp này; nếu tôi suy nghĩ đủ rõ ràng để xem xét đảo ngược chúng, tôi chắc chắn rằng tôi có thể đếm các dấu bằng.)

Điều chưa được đề cập là nhiều người (chắc chắn bao gồm cả tôi) thấy if (variable == constant)biểu mẫu này dễ đọc hơn - đó là một cách tự nhiên hơn để thể hiện bản thân. Đây là lý do để không sao chép một cách mù quáng một quy ước từ C. Bạn nên luôn đặt câu hỏi về thực tiễn (như bạn đang làm ở đây :) trước khi cho rằng những gì có thể hữu ích trong môi trường này lại hữu ích trong môi trường khác.

Điều này không có nhiều giá trị trong Java (1.5+) ngoại trừ khi loại đối tượng là Boolean. Trong trường hợp đó, điều này vẫn có thể hữu ích.

if (object = null)sẽ không gây ra lỗi biên dịch trong Java 1.5+ nếu có đối tượng Booleannhưng sẽ ném NullPointerExceptionvào thời gian chạy.

Trong Java không có lý do chính đáng.

Một số câu trả lời khác cho rằng đó là do bạn có thể vô tình làm cho nó bị gán thay vì bình đẳng. Nhưng trong Java, bạn phải có boolean trong if, vì vậy điều này:

if (o = null)

sẽ không biên dịch.

Lần duy nhất điều này có thể quan trọng trong Java là nếu biến là boolean:

int m1(boolean x)
{
    if (x = true)  // oops, assignment instead of equality

Điều này cũng liên quan chặt chẽ đến:

if ("foo".equals(bar)) {

điều này thuận tiện nếu bạn không muốn đối phó với NPE:

if (bar!=null && bar.equals("foo")) {

Thủ thuật này được cho là để ngăn chặn các v = nullloại lỗi chính tả.

Nhưng Java chỉ cho phép các biểu thức boolean làm if()điều kiện để thủ thuật đó không có nhiều ý nghĩa, trình biên dịch sẽ tìm ra những lỗi chính tả đó.

Tuy nhiên, nó vẫn là thủ thuật có giá trị đối với mã C / C ++.

Vì lý do tương tự, bạn làm điều đó trong C; phép gán là một biểu thức, vì vậy bạn đặt chữ ở bên trái để bạn không thể ghi đè nó nếu bạn vô tình sử dụng =thay thế ==.

Đó là đối với những người thích có hằng số ở bên trái. Trong hầu hết các trường hợp, việc có hằng số ở bên trái sẽ ngăn NullPointerException được ném (hoặc có một lần kiểm tra giá trị khác). Ví dụ, phương thức String bằng cũng kiểm tra null. Có hằng số ở bên trái, sẽ giúp bạn không phải viết séc bổ sung. Mà, theo một cách khác cũng được thực hiện sau đó. Có giá trị null ở bên trái chỉ là nhất quán.

giống:

 String b = null;
 "constant".equals(b);  // result to false
 b.equals("constant");  // NullPointerException
 b != null && b.equals("constant");  // result to false

Đó là điều kiện Yoda viết theo cách khác

Trong java

String myString = null;
if (myString.equals("foobar")) { /* ... */ } //Will give u null pointer

tình trạng yoda

String myString = null;
if ("foobar".equals(myString)) { /* ... */ } // will be false 

So sánh với đoạn mã sau:

    String pingResult = "asd";
    long s = System.nanoTime ( );
    if ( null != pingResult )
    {
        System.out.println ( "null != pingResult" );
    }
    long e = System.nanoTime ( );
    System.out.println ( e - s );

    long s1 = System.nanoTime ( );
    if ( pingResult != null )
    {
        System.out.println ( "pingResult != null" );
    }
    long e1 = System.nanoTime ( );
    System.out.println ( e1 - s1 );

Đầu ra (Sau nhiều lần thực hiện):

null != pingResult
325737
pingResult != null
47027

Do đó, pingResult != nulllà người chiến thắng.

Do tính chất giao hoán của nó , sự khác biệt duy nhất giữa object == nullvà null == object( phiên bản Yoda ) là về bản chất nhận thức : cách mã được đọc và tiêu hóa bởi người đọc. Tuy nhiên, tôi không biết câu trả lời chính xác, nhưng tôi biết cá nhân tôi thích so sánh đối tượng tôi đang kiểm tra với một thứ khác hơn là so sánh một thứ khác với đối tượng tôi đang kiểm tra , nếu điều đó có ý nghĩa. Bắt đầu với chủ đề, sau đó là giá trị để so sánh với nó.

Trong một số ngôn ngữ khác, kiểu so sánh này hữu ích hơn.

Mặc dù vậy, để bảo vệ an toàn khỏi dấu "=" bị thiếu, tôi nghĩ viết null == object là một hành động sai lầm trong lập trình phòng thủ . Cách tốt hơn đối với mã cụ thể này là đảm bảo hành vi bằng kiểm tra junit. Hãy nhớ rằng, lỗi có thể xảy ra khi thiếu dấu "=" không phụ thuộc vào các đối số đầu vào của phương thức - bạn không phụ thuộc vào việc người khác sử dụng đúng API này - vì vậy thay vào đó, kiểm tra junit là hoàn hảo để bảo vệ an toàn chống lại điều đó. Dù sao, bạn sẽ muốn viết các bài kiểm tra junit để xác minh hành vi; thiếu "=" đương nhiên nằm trong phạm vi.