Should methods that return boolean be named after a question or an assertion? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

Many naming conventions recommend that methods returning a boolean (also called predicate methods) should be named after a question. My question is: don't they really mean the methods should be named after an assertion?

The difference may be subtle, but you end up with different names in some cases:

• question: is_pixel_transparent(...)
• assertion: pixel_is_transparent(...)

Sometimes, this makes no difference and the phrasing is the same:

• question: end_of_file(...)
• assertion: end_of_file(...)

Besides, it seems like most of the time, what people call "questions" are actually assertions.

• key_exists(...) --> this is not a question, this is an assertion.
  Example usage: if (key_exists(...)) ...
• array_contains_element(...) --> this is not a question, this is an assertion.
  Example usage: if (array_contains_element(...)) ...

So, to restate the question, is everyone meaning assertion when they say question?

Answer 1

The point of naming conventions is not to make your code read like English, so you might be over-analyzing a bit. In many languages, it is customary to prefix a method or function returning a boolean result or a boolean variable with is, when it makes sense. There are other traditions (e.g. Lisp, Ruby), where a suffix ? is used instead. (An older Lisp tradition is the suffix -p for predicate).

• In your pixel transparency example, is_transparent should be a method of a pixel object. If you are in a language that does not have objects, but want to simulate an OOP style, then the type would usually be the prefix: Pixel_is_transparent. Note that the prefix is is only used to highlight the boolean nature of this method; it is already implied by the method call (pixel.transparent works as well, but this can become too ambiguous with other property names).
• To test for EOF, a method could be named at_eof. This interprets the end of file as a location in the stream, whereas stream.is_eof would work as well: here, the EOF is a specific state.
• To tests whether an entry exists, collection.exists(key) would be better.
• array_contains_element isn't a good method name, as it contains a type, and the unecessary element. Better: array.contains(elem).

All of the names I suggest are assertions, or more precisely: predicates. Using questions does not make any linguistic sense when these predicates are used in an if-then-else contex. The word “assertion” is probably not optimal here, as it is used to describe the testing of invariants in many languages. The word “predicate” would be better: a statement that is either true or false. A statement is phrased as if it were true, not as a question. The statement 1 ∈ {} – “1 is element of the empty set” or “the empty set contains 1” is a false statement. The question “does the empty set contain the number 1?” can be answered with yes or no, but it isn't true or false.