First a couple of examples:

var val = obj.GetValue();
var can = obj.CanPlay;
var has = obj.HasValue;
var val = obj.RequiresConstantRepaint(); // From Unity
var val = obj.PlayOnAwake; // From Unity
class RequireComponentAttribute // From Unity

As you can see, methods usually use first-person verbs, but not always.

Properties usually use thrid-person, but also not always.

There is the class RequireComponentAttribute in my example, it uses first-person verb. (Here is another problem: classes usually don't use verbs. But for attribute it maybe normal.)

Are there some rules how to choose either first-person or thrid-person verb?

  • Hint: PlayOnAwake is an action. PlaysOnAwake is a condition. – Robert Harvey Feb 8 at 18:02
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.

|improve this answer|||||
  • 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. – Martin Maat Feb 4 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 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 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(); } – Martin Maat Feb 5 at 22:12

I like the Flater's answer and Martin Maat's comment. But I think the answer should have more specific rules.

So I’ll try to explain how I understand it.

Let's divide properties and methods into categories:

  • Attribute (imperative verb, noun, adjective) - it allow us to ask/set object about some attribute/characteristic. Examples: (Will)PlayOnAwake, (Will)CloseWhenError, IgnoreXml, RequireComponent, Background, Nullable.

  • State (third-person verb) - it allows us to ask/set object about some state. Examples: HasValue, IsInitialized, IsDisposed, IsPlaying, AreEqual(a, b), Contains(value), RequiresComponent.

  • Value/Values/Data (noun) - it allows object to store/provide some data. Examples: Children, Parent, Content, Image.

  • Command (imperative verb) - it allows us to say object do something. Examples: SetValue(value), GetValue(), Initialize(), Dispose(), Play().

Note: Attributes and States should be considered as statement. It returns true/false when statement is right/wrong.

|improve this answer|||||
  • 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. – Martin Maat Feb 5 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 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 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.