52

Should boolean methods always take the affirmative form, even when they will only ever be used in the negative form?

Say I wanted to check whether an entity exists before creating one, my argument is that the first form below is better than the second form, whether or not the method is ever used in the affirmative form.

In summary, I find if(!affirmative) easier to read than if(negative). I have a colleague who disagrees, thoughts?

First Form:

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

Second Form:

int entity_id = 42;
if(entity_not_exist(entity_id)) create_entity(entity_id);
5
  • 4
    C++? how about if (not entity_exists(entity_id)) – Kos May 2 '13 at 15:36
  • related: Naming boolean variables: negated or not – gnat Jul 21 '16 at 11:16
  • to-may-to to-mah-to. Honestly, I have missed the ! character so many times causing me to mis-understand the code until I re-read it again. So I probably agree more with your coworker. I like the form that evaluates to true when you examine it. – Berin Loritsch Jul 20 '17 at 18:36
  • 1
    Just wanted to chime in to say that if (!exists) create() can be seen as a bad practice in many languages/frameworks, as it tends to not be thread-safe. Usually, the preferred approach is to call create() and handle specific exceptions or return codes saying that the entity already exists. This is of course not an answer to the actual question (which is why it is a comment only). – julealgon Sep 27 '18 at 17:44
  • You typically want to make the thing to signal the positive, you want to "raise the flag" for the case to be aware of. This COULD be a linguistic negative. You can then see if you can fix that (like naming something isMissing rather than exists). See also softwareengineering.stackexchange.com/questions/414575/… – Martin Maat Oct 15 '20 at 4:47
70

Should boolean methods always take the affirmative form, even when they will only ever be used in the negative form?

Making rules about such things seems a little much -- I wouldn't want to see a guideline in a coding standards document that says thou shalt not use negative names for boolean properties. But as a matter of personal style, I think trying to keep the names positive could be a fine ideal. However, I think it's also good to avoid the need for that skinny and easily-missed !. One can often find ways to turn a negative name into a positive one:

  • accountHasCharges
  • accountIsClear (same as !accountHasCharges)

Clarity is the most important consideration, and a good reason for avoiding negative method names is that they can lead to double negatives or worse:

  • isComplete // okay
  • isNotComplete // !isComplete is usually better
  • isIncomplete // could make sense if 'incomplete' is a known state of the object
  • !isNotComplete // horrible
  • !isNotComplete == 0 // may lead to permanent vacation
4
  • 5
    "I wouldn't want to see a guideline in a coding standards document that says thou shalt not use negative names for boolean properties." - I'll just leave this here... – AakashM May 2 '13 at 14:36
  • 22
    You forgot !isNotIncomplete – Ben Lee May 6 '13 at 18:55
  • So would the opposite of entity_exists be entity_should_be_created (instead of entity_not_exists)? Or perhaps entity_missing as per Dan's suggestion? – ADTC Sep 25 '14 at 9:20
  • 3
    This is where a coding standards document can use the word "prefer" rather than "should" or "must." – Wayne Conrad Jul 20 '17 at 17:48
16

I agree that the affirmative is easier to read. You might try

Third Form

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

or

Fourth Form

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

It also depends on how your method is going to be used. If it's going to be used in both the affirmative and negative cases, eg

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

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

Then the method name should be in the affirmative, like the above. If you're not sure how it's going to be used, then stick to the above.

But if it's ONLY used in the negative case, then the following is acceptable (maybe even desirable)

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

or even better reword it to be more affirmative

if (entity_is_absent(entity_id)) create_entity(entity_id);
0
  • The general rule: Use affirmative name on boolean method (or boolean variable, for that matter). And the reason is to avoid potential double negative if(!entity_not_exist(...)), which was already well-explained in the chosen answer here.

  • The seemingly special case (but not really): "if it's ONLY used in the negative case, then the following [negative form] is acceptable (maybe even desirable)":

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

    However, the problem is, in reality you can hardly foresee how a method or variable will be used, so you can not really make that assumption "it will ONLY be used in such way".

  • The real special case. If your boolean thing is an optional parameter of a function, you have 100% confidence on how it would be used inside your function, and then your goal becomes to define its default behavior to follow the convention of "absence means false".

    # Bad example
    def display(paragraph, wrap=None):
         # The domain knowledge wants wrapping behavior by default,
         # but the affirmative naming forces us to map both True and None to True.
         if wrap is True or wrap is None:  # ugly
             paragraph = reformat(paragraph)
         print(paragraph)
    
    # The default usage
    display("a long long long paragraph")  # This would wrap
    
    # But we need an explicit False for a different behavior, which feels weird.
    display("a long long long paragraph", wrap=False)  # Behaves different than the line above.
    

    The next one looks better, at least from outside of the function.

    # Better example
    def display(paragraph, no_wrap=None):
         # The domain knowledge wants wrapping behavior by default,
         # and the negative naming allows "absence means False" convention.
         if not no_wrap:  # Yes it is double negative,
                          # but it is at least not a compound condition.
             paragraph = reformat(paragraph)
         print(paragraph)
    
    # The default usage
    display("a long long long paragraph")  # This would wrap
    
    # The caller needs an explicit True to "turn on" a different behavior,
    # which feels normal.
    display("a long long long paragraph", no_wrap=True)  # This would not wrap
    
  • The practical trick. You can usually find a synonym in affirmative form to represent a once-negative meaning. :-)

    # Best way
    def display(paragraph, long_line=None):
         # The domain knowledge wants wrapping behavior by default.
         if not long_line:  # No more double negative
             paragraph = reformat(paragraph)
         print(paragraph)
    
    # The default usage
    display("a long long long paragraph")  # This would wrap
    
    # The caller needs an explicit True to "turn on" a different behavior,
    # which feels normal.
    display("a long long long paragraph", long_line=True)  # This would not wrap
    

Not the answer you're looking for? Browse other questions tagged or ask your own question.