Kiểm tra con trỏ NULL trong C / C ++ [đã đóng]

Trong một đánh giá mã gần đây, một người đóng góp đang cố gắng thực thi rằng tất cả các NULLkiểm tra về con trỏ được thực hiện theo cách sau:

int * some_ptr;
// ...
if (some_ptr == NULL)
{
    // Handle null-pointer error
}
else
{
    // Proceed
}

thay vì

int * some_ptr;
// ...
if (some_ptr)
{
    // Proceed
}
else
{
    // Handle null-pointer error
}

Tôi đồng ý rằng cách của anh ấy rõ ràng hơn một chút theo nghĩa rõ ràng là nói "Hãy chắc chắn rằng con trỏ này không phải là NULL", nhưng tôi sẽ phản bác lại rằng bằng cách nói rằng bất cứ ai làm việc với mã này đều hiểu rằng sử dụng biến con trỏ trong một iftuyên bố đang ngầm kiểm tra NULL. Ngoài ra tôi cảm thấy phương pháp thứ hai có cơ hội nhỏ hơn để giới thiệu một lỗi của ilk:

if (some_ptr = NULL)

đó chỉ là một nỗi đau tuyệt đối để tìm và gỡ lỗi.

Bạn thích cách nào và tại sao?

Theo kinh nghiệm của tôi, các bài kiểm tra của mẫu if (ptr)hoặc if (!ptr)được ưa thích. Họ không phụ thuộc vào định nghĩa của biểu tượng NULL. Họ không để lộ cơ hội cho sự phân công tình cờ. Và họ rõ ràng và cô đọng.

Chỉnh sửa: Như SoapBox chỉ ra trong một nhận xét, chúng tương thích với các lớp C ++ như auto_ptrlà các đối tượng đóng vai trò là con trỏ và cung cấp một chuyển đổi boolđể kích hoạt chính xác thành ngữ này. Đối với các đối tượng này, một so sánh rõ ràng NULLsẽ phải gọi một chuyển đổi sang con trỏ có thể có các tác dụng phụ ngữ nghĩa khác hoặc đắt hơn so với kiểm tra tồn tại đơn giản mà boolchuyển đổi ngụ ý.

Tôi có một ưu tiên cho mã nói ý nghĩa của nó mà không cần văn bản không cần thiết. if (ptr != NULL)có cùng ý nghĩa với if (ptr)nhưng với chi phí đặc thù dư thừa. Điều hợp lý tiếp theo là viết if ((ptr != NULL) == TRUE)và theo cách đó là sự điên rồ. Ngôn ngữ C rõ ràng là một boolean được kiểm tra bởi if, whilehoặc tương tự có ý nghĩa cụ thể của giá trị khác không là đúng và không là sai. Sự dư thừa không làm cho nó rõ ràng hơn.

if (foo)là đủ rõ ràng. Sử dụng nó.

Tôi sẽ bắt đầu với điều này: tính nhất quán là vua, quyết định ít quan trọng hơn tính nhất quán trong cơ sở mã của bạn.

Trong C ++

NULL được định nghĩa là 0 hoặc 0L trong C ++.

Nếu bạn đã đọc Ngôn ngữ lập trình C ++, Bjarne Stroustrup gợi ý sử dụng 0rõ ràng để tránh NULLmacro khi thực hiện bài tập , tôi không chắc liệu anh ta có làm như vậy với các so sánh hay không, đã một thời gian kể từ khi tôi đọc cuốn sách, tôi nghĩ anh ta đã làm if(some_ptr)không có một so sánh rõ ràng nhưng tôi mờ về điều đó.

Lý do cho điều này là vì NULLmacro là lừa đảo (vì gần như tất cả các macro) nó thực sự là 0theo nghĩa đen, không phải là một loại duy nhất như tên cho thấy nó có thể. Tránh macro là một trong những hướng dẫn chung trong C ++. Mặt khác, 0trông giống như một số nguyên và nó không phải là khi so sánh với hoặc được gán cho con trỏ. Cá nhân tôi có thể đi một trong hai cách, nhưng thông thường tôi bỏ qua so sánh rõ ràng (mặc dù một số người không thích điều này có lẽ là lý do tại sao bạn có một cộng tác viên đề nghị thay đổi bằng mọi cách).

Bất kể cảm xúc cá nhân, điều này phần lớn là một sự lựa chọn ít xấu xa nhất vì không có một phương pháp đúng đắn.

Điều này là rõ ràng và là một thành ngữ phổ biến và tôi thích nó, không có cơ hội vô tình gán một giá trị trong khi so sánh và nó đọc rõ ràng:

if(some_ptr){;}

Điều này là rõ ràng nếu bạn biết đó some_ptrlà một loại con trỏ, nhưng nó cũng có thể trông giống như một so sánh số nguyên:

if(some_ptr != 0){;}

Điều này rất rõ ràng, trong những trường hợp thông thường, nó có ý nghĩa ... Nhưng đó là một sự trừu tượng bị rò rỉ, NULLthực sự 0theo nghĩa đen và cuối cùng có thể dễ dàng bị lạm dụng:

if(some_ptr != NULL){;}

C ++ 0x có nullptr hiện là phương thức ưa thích vì nó rõ ràng và chính xác, chỉ cần cẩn thận về việc gán ngẫu nhiên:

if(some_ptr != nullptr){;}

Cho đến khi bạn có thể di chuyển sang C ++ 0x, tôi sẽ cho rằng thật lãng phí thời gian để lo lắng về phương pháp nào bạn sử dụng, tất cả đều không đủ, đó là lý do tại sao nullptr được phát minh (cùng với các vấn đề lập trình chung đưa ra chuyển tiếp hoàn hảo .) Điều quan trọng nhất là duy trì tính nhất quán.

Trong C

C là một con thú khác nhau.

Trong C NULL có thể được định nghĩa là 0 hoặc là ((void *) 0), C99 cho phép thực hiện các hằng số con trỏ null được xác định. Vì vậy, nó thực sự đi vào định nghĩa của NULL và bạn sẽ phải kiểm tra nó trong thư viện chuẩn của mình.

Macro rất phổ biến và nói chung chúng được sử dụng rất nhiều để bù đắp cho những thiếu sót trong hỗ trợ lập trình chung trong ngôn ngữ và những thứ khác. Ngôn ngữ đơn giản hơn nhiều và sự phụ thuộc vào bộ xử lý trước phổ biến hơn.

Từ quan điểm này, tôi có thể khuyên bạn nên sử dụng NULLđịnh nghĩa macro trong C.

Tôi sử dụng if (ptr), nhưng điều này là hoàn toàn không đáng tranh luận.

Tôi thích cách của tôi vì nó ngắn gọn, mặc dù những người khác nói == NULLgiúp đọc dễ dàng và rõ ràng hơn. Tôi thấy họ đến từ đâu, tôi chỉ không đồng ý những thứ bổ sung giúp mọi việc dễ dàng hơn. (Tôi ghét macro, vì vậy tôi thiên vị.) Tùy bạn.

Tôi không đồng ý với lập luận của bạn. Nếu bạn không nhận được cảnh báo cho các bài tập trong một điều kiện, bạn cần phải tăng mức cảnh báo của mình lên. Đơn giản như vậy. (Và vì tình yêu là tốt, đừng chuyển chúng đi.)

Lưu ý trong C ++ 0x, chúng ta có thể làm if (ptr == nullptr), mà với tôi không đẹp hơn đọc. (Một lần nữa, tôi ghét macro. Nhưng nullptrthật tuyệt.) Tôi vẫn làm if (ptr), mặc dù, chỉ vì đó là những gì tôi đã từng làm.

Thành thật mà nói, tôi không thấy lý do tại sao nó quan trọng. Một trong hai là khá rõ ràng và bất cứ ai có kinh nghiệm vừa phải với C hoặc C ++ nên hiểu cả hai. Một bình luận, mặc dù:

Nếu bạn có kế hoạch nhận ra lỗi và không tiếp tục thực thi chức năng (nghĩa là bạn sẽ ném ngoại lệ hoặc trả lại mã lỗi ngay lập tức), bạn nên biến nó thành mệnh đề bảo vệ:

int f(void* p)
{
    if (!p) { return -1; }

    // p is not null
    return 0;
}

Bằng cách này, bạn tránh được "mã mũi tên."

Cá nhân tôi luôn sử dụng if (ptr == NULL)vì nó làm cho ý định của tôi rõ ràng, nhưng tại thời điểm này, đó chỉ là một thói quen.

Sử dụng =thay thế ==sẽ bị bắt bởi bất kỳ trình biên dịch có thẩm quyền với các cài đặt cảnh báo chính xác.

Điểm quan trọng là chọn một phong cách nhất quán cho nhóm của bạn và bám sát nó. Cho dù bạn đi theo con đường nào, cuối cùng bạn cũng sẽ quen với nó và việc mất ma sát khi làm việc trong mã của người khác sẽ được hoan nghênh.

Chỉ cần thêm một điểm có lợi cho foo == NULLthực tiễn: Nếu foolà, giả sử, int *hoặc bool *, thì if (foo)kiểm tra có thể vô tình được người đọc hiểu là kiểm tra giá trị của điểm, tức là if (*foo). Sự NULLso sánh ở đây là một lời nhắc nhở rằng chúng ta đang nói về một con trỏ.

Nhưng tôi cho rằng một quy ước đặt tên tốt làm cho tranh luận này được đưa ra.

Trên thực tế, tôi sử dụng cả hai biến thể.

Có những tình huống, trước tiên bạn kiểm tra tính hợp lệ của một con trỏ và nếu đó là NULL, bạn chỉ cần trả về / thoát khỏi hàm. (Tôi biết điều này có thể dẫn đến cuộc thảo luận "nếu một chức năng chỉ có một điểm thoát")

Hầu hết thời gian, bạn kiểm tra con trỏ, sau đó làm những gì bạn muốn và sau đó giải quyết trường hợp lỗi. Kết quả có thể là mã thụt lề x lần xấu xí với nhiều if.

Ngôn ngữ lập trình C (K & R) sẽ giúp bạn kiểm tra null == ptr để tránh việc gán ngẫu nhiên.

Nếu phong cách và định dạng sẽ là một phần trong các đánh giá của bạn, cần có một hướng dẫn về phong cách đã được thống nhất để đo lường. Nếu có một, làm những gì hướng dẫn phong cách nói. Nếu không có ai, các chi tiết như thế này sẽ được để lại khi chúng được viết. Đó là một sự lãng phí thời gian và năng lượng, và làm mất tập trung vào những gì các bài đánh giá mã thực sự nên được phát hiện ra. Nghiêm túc mà nói, không có hướng dẫn về phong cách, tôi sẽ cố gắng KHÔNG thay đổi mã như thế này như một vấn đề nguyên tắc, ngay cả khi nó không sử dụng quy ước mà tôi thích.

Và không phải là vấn đề, nhưng sở thích cá nhân của tôi là if (ptr). Ý nghĩa rõ ràng ngay lập tức với tôi hơn cảif (ptr == NULL) .

Có lẽ anh ta đang cố gắng nói rằng tốt hơn là xử lý các điều kiện lỗi trước con đường hạnh phúc? Trong trường hợp đó tôi vẫn không đồng ý với người đánh giá. Tôi không biết rằng có một quy ước được chấp nhận cho điều này, nhưng theo tôi, điều kiện "bình thường" nhất phải được ưu tiên hàng đầu trong bất kỳ tuyên bố if nào. Bằng cách đó, tôi đã ít phải đào bới để tìm ra chức năng là gì và hoạt động như thế nào.

Ngoại lệ cho điều này là nếu lỗi khiến tôi phải bảo lãnh từ chức năng hoặc tôi có thể khôi phục từ đó trước khi tiếp tục. Trong những trường hợp đó, tôi xử lý lỗi trước:

if (error_condition)
  bail_or_fix();
  return if not fixed;

// If I'm still here, I'm on the happy path

Bằng cách đối phó với tình trạng bất thường ở phía trước, tôi có thể chăm sóc nó và sau đó quên nó đi. Nhưng nếu tôi không thể quay lại con đường hạnh phúc bằng cách xử lý nó trước, thì nó sẽ được xử lý sau vụ án chính vì nó làm cho mã dễ hiểu hơn. Theo ý kiến ​​của tôi.

Nhưng nếu nó không theo hướng dẫn về phong cách thì đó chỉ là ý kiến ​​của tôi và ý kiến ​​của bạn cũng có giá trị. Hoặc tiêu chuẩn hóa hoặc không. Đừng để người đánh giá giả chuẩn hóa chỉ vì anh ta có ý kiến.

Đây là một trong những nguyên tắc cơ bản của cả hai ngôn ngữ mà con trỏ đánh giá về một loại và giá trị có thể được sử dụng làm biểu thức kiểm soát, booltrong C ++ và inttrong C. Chỉ cần sử dụng nó.

• Con trỏ không phải là booleans
• Trình biên dịch C / C ++ hiện đại phát ra cảnh báo khi bạn viết một if (foo = bar)cách tình cờ.

Vì vậy tôi thích

if (foo == NULL)
{
    // null case
}
else
{
    // non null case
}

hoặc là

if (foo != NULL)
{
    // non null case
}
else
{
    // null case
}

Tuy nhiên, nếu tôi đang viết một bộ hướng dẫn về phong cách, tôi sẽ không đặt những thứ như thế này vào đó, tôi sẽ đặt những thứ như:

Hãy chắc chắn rằng bạn thực hiện kiểm tra null trên con trỏ.

Tôi là một fan cuồng nhiệt của thực tế là C / C ++ không kiểm tra các loại trong điều kiện boolean trong if, forvà whilebáo cáo. Tôi luôn luôn sử dụng như sau:

if (ptr)

if (!ptr)

thậm chí trên các số nguyên hoặc loại khác chuyển đổi thành bool:

while(i--)
{
    // Something to do i times
}

while(cin >> a >> b)
{
    // Do something while you've input
}

Mã hóa theo phong cách này dễ đọc và rõ ràng hơn đối với tôi. Chỉ là ý kiến ​​cá nhân của tôi.

Gần đây, khi làm việc trên bộ vi điều khiển của máy quay phim 431, tôi đã nhận thấy rằng:

unsigned char chx;

if (chx) // ...

hiệu quả hơn

if (chx == 1) // ...

bởi vì trong trường hợp sau, trình biên dịch phải so sánh giá trị của chx với 1. Trong đó chx chỉ là một cờ đúng / sai.

Hầu hết các trình biên dịch mà tôi đã sử dụng ít nhất sẽ cảnh báo về ifbài tập mà không cần thêm cú pháp đường, vì vậy tôi không mua đối số đó. Điều đó nói rằng, tôi đã sử dụng cả chuyên nghiệp và không có ưu tiên cho một trong hai. Điều == NULLnày chắc chắn rõ ràng hơn theo ý kiến ​​của tôi.