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

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);

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);

• 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