56

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);
lynks
  • 663
  • 1
  • 5
  • 6
  • 4
    C++? how about `if (not entity_exists(entity_id))` – Kos May 02 '13 at 15:36
  • related: [Naming boolean variables: negated or not](http://programmers.stackexchange.com/questions/245375/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 https://softwareengineering.stackexchange.com/questions/414575/negative-naming-in-forms/414579#414579 – Martin Maat Oct 15 '20 at 04:47

4 Answers4

75

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
Caleb
  • 38,959
  • 8
  • 94
  • 152
  • 6
    "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...](http://msdn.microsoft.com/en-us/library/vstudio/ms229012.aspx) – AakashM May 02 '13 at 14:36
  • 26
    You forgot `!isNotIncomplete` – Ben Lee May 06 '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 09:20
  • 5
    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
  • "thou shalt"? Can you imagine this site being visited by more than just Victorian sirs? – Max Yudin Jul 19 '23 at 19:51
  • @MaxYudin It's been ten years, but IIRC I wrote it that way to make it sound like a commandment, since a number of the Ten Commandments are commonly written in English such that they start with *thou shalt not*, e.g. *Thou shalt not make unto thee any graven image*, etc. The point is that while it's probably good to avoid negatives in names generally, I wouldn't prohibit it completely. – Caleb Jul 21 '23 at 13:51
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);
Community
  • 1
Dan Pichelman
  • 13,773
  • 8
  • 42
  • 73
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);
Zack Xu
  • 121
  • 1
1

  • 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
RayLuo
  • 651
  • 6
  • 8