I have seen examples of methods whose name ended with a preposition applying to the first (and most often only) parameters. But other examples don't use this kind of naming convention. Which do you think is more readable? For example, should I make a method like this:

getColorFor(Player player)

or like this?

getColor(Player player)

In this scenario, the method would return a color that represents the player supplied as parameter.

  • 3
    Swift/ObjC users have a third option: define getColor(for player: Player) and call like board.getColor(for: redPlayer) – snipsnipsnip Sep 24 '18 at 7:58

If it adds meaningful clarification or fits the "ethos" ... Yes.

.NET's OrderBy() and ElementAt() might be good examples.

Personally, I like code that reads pretty much like English. It takes a ton of guesswork, hovering and digging, and arcane knowledge out of reading someone's code when it tells me unambiguously what it does.

And as far as I can tell, I'm not the only one who feels this way.

  • 1
    I use it sparingly for risk of overuse and making things read stilted. Nonetheless I'm always on the lookout for the opportunity; if the argument name(s)/literals fit well grammatically. – radarbob Sep 29 '18 at 1:33

While shorter is better, sometimes the best fit for a short word requires disambiguation. A humorous example:

var translator = new Translator();
var result = translator.French("sister");
//throws TargetIsMarriedException

This is better:

var translator = new Translator();
var result = translator.FrenchFor("sister");
//sets result to "soeur"

This is probably the reasoning behind some of Microsoft's own examples of compound names, for example:

@html.TextBoxFor( m => m.Field );

It can be especially helpful if the first word could be either a noun or a verb, for example:


might be either



  • 1
    shorter is pretty much never "better" clearer and concise (ie easiest to understand) the better. Sometimes the shorter of two options (non abreviated) is easier to understand, but there are a lot of times when this isn't true. – opa Sep 21 '18 at 16:55

Although it seems an interesting idea, I think it's overkill. I have never seen it used.

There is no need to re-form complete English language syntax in a name, especially if it adds no value - the shorter name will be perfectly clear to even beginner programmers.

  • Thanks, I will avoid using it then. I do remember seeing it somewhere, but not the specific place, but as soon as I see it again, I will update my question. Maybe it will go back to 0 at least:D – user3738870 Sep 20 '18 at 23:57
  • 3
    Never?. . Not ever? – svidgen Sep 21 '18 at 1:11
  • 1
    Never seen its use? You need to get out more :) This is a very common naming pattern in my experience. I personally would go further an name the function getColorForPlayer, but getColorFor is a good choice as it guides me to look at the parameter for more details. getColor tells me nothing about what the function does beyond getting a colour from some unspecified place. It's a poor choice of name in my view. – David Arno Sep 21 '18 at 8:10
  • @DavidArno depends on the language. In OP's example its pretty obvious that it's for a Player. And, the method could be overloaded to handle Monster, BadGuy, etc... – user949300 Sep 21 '18 at 17:03

An interesting question.

I agree with @Aganju that it is overkill.

The ()'s alone mean something like "with" or "by" or "in the context of" these arguments, so no need for that in the text of the identifier that names the function. 

In many languages, if you use the identifier getColor without the ()'s then that refers to the function or method itself rather than an invocation of it; for example, if you want to pass the function itself as a parameter somewhere for someone else to use.  I suppose that formally the ()'s means "apply" the arguments to that function.  This is seen sometimes in functional programming oriented languages, and also JavaScript, for example, has bind, and apply.

If you use OOP, then we might see: player.getColor() which makes it read somewhat clear that getColor is being done by player (possibly in the context of ("with") other arguments, if it takes them).

Further, the notion of adding a preposition probably does not scale well for more parameters.

Some, but not all, languages offer naming actual arguments at the call site (by the formal parameter name) so you can do getColor(for:=player), and, with that you'd get to provide descriptive names (that could be prepositions or more) for multiple parameters.

  • Yes, I do use an OO language (good ol' C++), but in my design, Player class is not responsible for knowing its color, because I wanted to separate UI-related responsibilities as much as possible. – user3738870 Sep 21 '18 at 9:58

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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