Here are a few examples:

  • Imperative verb

    • Initialize!
    • InitializeWhenCreated!
    • RequireValue!
  • Third-person verb

    • HasValue?
    • RequiresValue?

Are there some rules how to choose either imperative verb or third-person verb to use?

  • I'd say for methods, fields and properties it's pretty simple: if you return a boolean to indicate the state or capability of something I'd use the third-person verb (Can-, Has-, Requires-, Is-), if you return anything else I'd use Get- or Create- or Calculate- or something, if you are issuing a command not returning anything, I use an imperative verb (like your PlayOnAwake). One exception: if you return whether a command succeeded or not, I'd also use imperative.
    – Quido
    Aug 9 at 15:24
var val = obj.GetValue();
var val = obj.PlayOnAwake; // From Unity

It's not first-person, it's imperative. Simply put, it's a command.

  • GetValue() Get the value!
  • PlaySound() Play this sound!
  • DeleteFile() Delete that file!

These namings are used for methods, especially methods that perform a task (as opposed to returning a known value).

var has = obj.HasValue;

What you're calling third-person, is inquisitive. It poses a question, specifically a yes/no question, because it's representing a boolean nature.

  • isReadOnly Is this file readonly?
  • requiresConstantRepaint Does this object require a constant repaint?
  • isAdmin Is the user an administrator?

These namings are used for booleans, as the yes/no nature of the phrasing mirrors the true/false nature of the boolean.

var val = obj.RequiresConstantRepaint(); // From Unity

There are some methods whose boolean return value are their sole purpose. These methods tend to follow boolean (question) naming schemes instead of method (imperative) naming schemes, to further highlight their purpose of providing a true/false (yes/no) distinction.

class RequireComponentAttribute // From Unity

Attributes follow a slightly different approach. Their naming is not as consistent and is often less semantically inclined than the method/boolean namings mentioned before.

  • [XmlIgnore] is a stilted imperative ("ignore this in XML form")
  • [Fact] is a noun
  • [Obsolete] is an adjective

Most commonly, nouns and adjectives are used since attributes are commonly read as "extra" descriptions tacked on to a class/method/property. But there is no hard line to draw here compared to the much more conventionalized method/boolean namings mentioned before.

  • 2
    I agree with the command part for methods, these take the form DoSomething(). For properties I would explain the singular form by stating they are about an object (1 object). So it naturally becomes "this object has" and "this object is". It is not a question, it is a statement about one thing. Feb 4 '20 at 6:24
  • 1
    @MartinMaat: It's arguable whether you consider boolean naming inquisitive or declarative. Given the tendency for it to start with a verb, I interpret that as the inversion that is used in questions (i.e. "I am hungry" vs "am I hungry"). But I do see that you could interpret it as having an omitted subject because telegram style being used. You're right that myObject.IsAlive seems to use myObject as the subject of the sentence, but the naming scheme for booleans is still the same even when it's not a class field/property (bool isAlive;).
    – Flater
    Feb 5 '20 at 9:43
  • Thank you guys. I wrote my answer, but I still don't understand one thing. May be you have some ideas. softwareengineering.stackexchange.com/a/404752/352915
    – Denis535
    Feb 5 '20 at 22:01
  • @Flater Yes, we do see that a lot: bool isAlive. I would argue though this is either lazy or a misunderstanding on the coder's part. The question immediately pops up "WHAT is alive? It should be threadIsAlive or isThreadAlive. In the latter case it would be a question as you say but this does not work well as a conditional statement so I would always prefer the first form, which reads more naturally: if (threadIsAlive) { DoStuff(); } Feb 5 '20 at 22:12
  • 1
    Also, watch out for non-imperatives that are named like imperatives. I was calling a method named toggleLeftNavButton() that wasn't working. Upon further investigation, it turns out it didn't mean "toggle left-nav-button" but rather "toggle-left-nav button", i.e. the method returns a reference to the button that toggles the left nav, and then I have to click on that button (using Selenium). I renamed it to leftNavToggleButton().
    – Kyralessa
    Oct 1 at 6:05

First, there are the next member kinds:

Secondly, there are the following naming rules:

  • Noun
  • Adjective
  • Verb (imperative mood)
  • Verb (third-person)
  • Adverb

So let's sum up:

  • Members of command or directive kind are using imperative mood.
  • Members of question kind are using third-person.
  • 2
    Using read-write properties for invoking actions is not a good idea for this very reason. Properties represent state. They may have side effects but if the side effect becomes the main thing we should use a method instead. Feb 5 '20 at 22:22
  • obj.IsPlaying = false/true; It can be considered as: either an action or just state changing. Problem with properties like: DoXXXWhenYYY. I don't understand what is it. Not action, not state. Somethigs like attribute.
    – Denis535
    Feb 5 '20 at 22:35
  • Obj.isPlaying = true: Changes the state to isPlaying = true. What’s tricky: In an audio player object I would expect this to start sound. In an object that uses an audio player it might just record the state of the audio player, which I would say is misguided. In that situation the setter should pass the setting on to the audio player.
    – gnasher729
    Feb 8 '20 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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