Method naming conventions for common type of functions

Question

Problem description

I often find myself thinking about a method name for the function I'm about the write. Like setters and getters to change or get the object's state. Maybe I am using objects not in the right way, but I often find myself in situations where using setters and getters do not seem to fit that well. I got a few specific questions.

Questions

1. Is it preferred to use standardized method names or rather use method names which are in the domain of the problem you're solving? (E.g. in a game you could use boolean won, isWinner()).
2. When would abbreviations be appropriate? And how should you abbreviate? I often find myself creating abbreviations when I have to write it a lot, but that seems like a bad criteria because code-reviewers should in my opinion drop in a method and understand what is going on. With "how should you abbreviate" I mean this: should message be; msg, mes, and for example average; avg, av, or initializing, init, initialize etc..
3. Are there reasons why you should put the methods main functionality at the end? For instance, welcomeMsg() (functionality at the end), msgWelcome() (functionality in front).
4. Do you only have 3 different kind of methods? Setters (used for updating, initializing), getters and condition tests? So you can basically see subdevide all methods between these 3?

Particular situations

In particular I have had some problems with naming in these kind of situations where I was creating a hangman game. In which a hidden string is presented masked by underscores, each time the user enters a correct letter the masked string is updated with the correct letter in the correct place. Here are some method names I used and have questions about:

• welcomeMessage() {} //could be either msgWelcome, welcomeMsg, there will be many more messages. What is a good way for message method names?

• initialiseGame() {} //could as well be initGame or setupGame changing, ugh.

• checkIfWon() {} //hasWon() is probably better.

• askUserInput() {} //seems like a common thing to do, what is a good way to do this, is creating a method for this common or do people often do this inline within an other method? The userinput should match specific conditions.

• countMatches() {}//to check how many of the letters given by the userInput match the hidden word. calculateMatches(), enumMatches(), enumerateMatches(), getMatches all seem plausible alternatives.

• containsOnlyLetters(String string) {}//checks if input contains only letters. isOnlyLetters() makes it more clear that it is a boolean, but seems to be further away from problem description.

Answer 1

Good questions. Note that some of what I say are my opinion. Whatever your style is, it is good to be consistent in your own code and mostly standardized with how everyone else does things.

1. Is it preferred to use standardized method names or rather use method names which are in the domain of the problem you're solving?

When I can, I use the domain language for method names, and try to make those names verbs. For example, bankAccount.Deposit(new Money(200)); instead of bankAccount.setMoney(new Money(200));

Using the domain language usually reads nicer and makes your objects feel more abstract and closer to what you are actually modelling. When you can't think of a nice domain specific name for a method, I usually resort to the standard prefixes (get, set, is/has/etc).

2. When would abbreviations be appropriate? And how should you abbreviate?

I almost never abbreviate. Sure, it's a pain in the butt to see and write long method names, but you often have the aid of an auto-complete IDE. I personally find it annoying seeing a variable/method/class name that are abbreviated. It makes me stop for a second, and try to dicipher the meaning. I like code that reads well, and I think abbreviations cut down on readability. There are some abbreviations that are good though. NHL, NFL, etc. There's also common abbreviations, like msg for message, num for number, etc. I don't necessarily MIND those, but for consistency, I usually don't abbreviate at all. I would say be consistent, but lean more towards not abbreviating.

3. (a) Are there reasons why you should put the methods main functionality at the end?

In these cases, I go with what reads better. Using this method in code, does it read better like: System.out.println(hangmanGame.welcomeMessage()); or System.out.println(hangmanGame.msgWelcome());? I prefer the former. If I were writing this, I would make this method into a verb, and it would probably be System.out.println(hangmanGame.getWelcomeMessage());

3. (b)Do you only have 3 different kind of methods? Setters (used for updating, initializing), getters and condition tests?

Yes, those are the only 3 types of methods that you have. Technically, you only have two types: mutators, and accessors (setters, getters), since returning a boolean is a getter. So, you either call a method on an object to change its state, or to get it's state.

Bullet1: Answered in 3(a)

Bullet2: Doesn't really matter, but if you want an opinion, I like setupGame. In the domain of a game, games are setup, and not initialized :).

Bullet3: I like hasWon() a lot better. if (player.hasWon()) instead of if (player.checkIfWon()).

Bullet4: I prefer getMatches() here, but even more so getMatchCount() (if the count is what you are after). I like the get prefix because it tells the programmer the method is returning something. From countMatches(), you don't really know without looking at the method signature if it will return something or not.

Bullet5: I'm torn on this one, but if I had to choose, I would go with containsOnlyLetters, because the Java String class has a function contains. As long as the method name sound like you're interrogating the class, then it's reasonable to assume that it returns a boolean. That is to say, you don't have to use the is prefix.

Hope this helps.

Answer 2

1. in the domain you're in. It makes your code more easily comprehendible which benefits you and others.

2. just abbreviate to your liking and be consistent. For example: msg/mes, init, alloc, avg/average, min & max. If it is as understandable, but shorter, then it's good to use.

3. I would make that an imperative command, like showWelcomeMsg() or showMsg(WELCOME), this way it's much clearer what will actually happen. If it isn't a function, I'd go for welcomeMsg as it reads nicer.

initGame (more like initializing the game state, but not creating it) or setupGame (all-in-one function) will do. hasWon, no need for being unnecessarily verbose. getMatchesCount is okay to get just the count, however, since you also need to display them I would make getMatches return an array with all the matching letters. countMatches isn't really clear on its return value. It could also be void and set internal variables, etc. isOnlyLetters (public) or lettersOnly (private/local).

You seem to be overanalyzing, though, making the task unnecessary complex. Just focus on consistency, readability and understandability while not being too elaborately.