Phương pháp Boolean Đặt tên khẳng định vs phủ định


43

Các phương pháp boolean có nên luôn luôn ở dạng khẳng định, ngay cả khi chúng sẽ chỉ được sử dụng ở dạng phủ định?

Nói rằng tôi muốn kiểm tra xem một thực thể có tồn tại trước khi tạo một thực thể hay không, đối số của tôi là hình thức đầu tiên bên dưới tốt hơn hình thức thứ hai, cho dù phương thức đó có được sử dụng ở dạng khẳng định hay không.

Tóm lại, tôi thấy if(!affirmative)dễ đọc hơn if(negative). Tôi có một đồng nghiệp không đồng ý, suy nghĩ?

Mẫu đầu tiên:

int entity_id = 42;
if(!entity_exists(entity_id)) create_entity(entity_id);

Dạng thứ hai:

int entity_id = 42;
if(entity_not_exist(entity_id)) create_entity(entity_id);

3
C ++? làm thế nào vềif (not entity_exists(entity_id))
Kos


to-may-to-mah-to. Thành thật mà nói, tôi đã bỏ lỡ !nhân vật rất nhiều lần khiến tôi hiểu sai mã cho đến khi tôi đọc lại nó. Vì vậy, tôi có thể đồng ý nhiều hơn với đồng nghiệp của bạn. Tôi thích hình thức đánh giá là đúng khi bạn kiểm tra nó.
Berin Loritsch

Chỉ muốn kêu vang để nói rằng if (!exists) create()có thể được coi là một thực tiễn xấu trong nhiều ngôn ngữ / khung, vì nó có xu hướng không an toàn cho chuỗi. Thông thường, cách tiếp cận ưa thích là gọi create()và xử lý các trường hợp ngoại lệ cụ thể hoặc trả về mã nói rằng thực thể đã tồn tại. Tất nhiên đây không phải là một câu trả lời cho câu hỏi thực tế (đó là lý do tại sao nó chỉ là một nhận xét).
julealgon

Câu trả lời:


61

Các phương pháp boolean có nên luôn luôn ở dạng khẳng định, ngay cả khi chúng sẽ chỉ được sử dụng ở dạng phủ định?

Việc đưa ra các quy tắc về những điều như vậy có vẻ hơi nhiều - tôi sẽ không muốn xem hướng dẫn trong tài liệu tiêu chuẩn mã hóa nói rằng bạn sẽ không sử dụng tên phủ định cho các thuộc tính boolean . Nhưng như một vấn đề của phong cách cá nhân, tôi nghĩ cố gắng giữ cho các tên tích cực có thể là một lý tưởng tốt. Tuy nhiên, tôi nghĩ cũng tốt để tránh sự cần thiết cho sự gầy gò và dễ bị bỏ qua đó !. Người ta thường có thể tìm cách biến một tên tiêu cực thành một tên tích cực:

  • accountHasCharges
  • accountIsClear(giống như !accountHasCharges)

Sự rõ ràng là sự cân nhắc quan trọng nhất và một lý do chính đáng để tránh các tên phương thức phủ định là chúng có thể dẫn đến tiêu cực kép hoặc tệ hơn:

  • isComplete // Được chứ
  • isNotComplete //! isComplete thường tốt hơn
  • isIncomplete // có thể có nghĩa nếu 'không đầy đủ' là trạng thái đã biết của đối tượng
  • !isNotComplete // kinh khủng
  • !isNotComplete == 0 // có thể dẫn đến kỳ nghỉ vĩnh viễn

5
"Tôi sẽ không muốn xem một hướng dẫn trong tài liệu tiêu chuẩn mã hóa nói rằng bạn sẽ không sử dụng tên phủ định cho các thuộc tính boolean ." - Tôi sẽ để nó ở đây ...
AakashM

16
Bạn đã quên!isNotIncomplete
Ben Lee

Vì vậy, điều ngược lại entity_existssẽ là entity_should_be_created(thay vì entity_not_exists)? Hoặc có lẽ entity_missingtheo đề nghị của Dan?
ADTC

1
Đây là nơi một tài liệu tiêu chuẩn mã hóa có thể sử dụng từ "thích" hơn là "nên" hoặc "phải".
Wayne Conrad

15

Tôi đồng ý rằng lời khẳng định là dễ đọc hơn. Bạn có thể thử

Mẫu thứ ba

int entity_id = 42;
if (entity_is_missing(entity_id)) create_entity(entity_id);

hoặc là

Mẫu thứ tư

int entity_id = 42;
if (is_entity_missing(entity_id)) create_entity(entity_id);

2

Nó cũng phụ thuộc vào cách phương pháp của bạn sẽ được sử dụng. Nếu nó sẽ được sử dụng trong cả hai trường hợp khẳng định và phủ định, vd

if (!entity_exists(entity_id)) create_entity(entity_id);

if (entity_exists(entity_id)) publish_entity(entity_id);

Sau đó, tên phương thức nên được khẳng định, như trên. Nếu bạn không chắc chắn nó sẽ được sử dụng như thế nào, thì hãy bám vào phần trên.

Nhưng nếu nó CHỈ được sử dụng trong trường hợp tiêu cực, thì những điều sau đây có thể chấp nhận được (thậm chí có thể được mong muốn)

if (entity_not_exists(entity_id)) create_entity(entity_id);

hoặc thậm chí tốt hơn để điều chỉnh lại để được khẳng định hơn

if (entity_is_absent(entity_id)) create_entity(entity_id);
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.