8

if I had a boolean (property) shouldAutoLogin is it better to name the getter getShouldAutoLogin or just shouldAutoLogin so that it reads more like English?

ex :

if(shouldAutoLogin){
    ...
}

or

if(getShouldAutoLogin){
    ...
}
  • Is the a property named 'shouldAutoLogin'? Reflection in some languages (for example, jsp frameworks) expect that ${foo.something} be translated into foo.getSomething() behind the scenes. – user40980 Jul 24 '13 at 14:51
  • That seems to be the norm. For boolean values however it's also common to use isFoo() instead of getFoo(). In your example that would be isAutoLogin() – rath Jul 24 '13 at 14:54
  • If you want to access any of those classes from a jsp, you pretty much have to. – Jaydee Jul 24 '13 at 15:32
  • @jmoreno while I (and others) have mentioned Java, it isn't clear that the OP is talking of it (if anything, given the choice of expressions inside of if() it is unlikely that it is Java. – user40980 Jul 24 '13 at 15:48
  • 7
    @MikeBryant Naming conventions are language specific. – CodesInChaos Jul 24 '13 at 16:34
9

The naming convention for getters are normally,

getAutoLogin() if getting some string or object.

isAutoLogin() for boolean.

| improve this answer | |
  • 11
    This is naming convention for java which is part of JavaBeans. For c# you declare the property names without any prefix like get/set/is. – k3b Jul 24 '13 at 15:27
  • @k3b Thanks for the info. I am a Java Developer. :) But its good to know about C# convention too. Thanks – JNL Jul 24 '13 at 15:35
  • 2
    This question is about getters/setters, not properties. I thought getters and setters in C# usually start by get* or set* too (see for example stackoverflow.com/questions/16718772/…). – sergut Jul 24 '13 at 17:21
  • 1
    @sergut: True, but if the getter/setter methods are fast and idempotent, one would normally favor properties over getter and setter methods. If they are not idempotent, get and set prefixes are probably misleading. If they are not fast, get and set prefixes should probably be replaced with prefixes which make it more obvious that there are costs (e.g, use "calculateFrob" instead of "getFrob"). – Brian Jul 24 '13 at 20:18
  • @Brian I was looking for some more clarification. The way I saw getters and setter were ONLY to get the private data and set the data. In the previous comment when you gave an example of calculateFrob(), that would be more like an operation/calculation to be done on the private data. That calculation can also be temporary and we might not need to set the private data. I hope you getting, the point I am trying to make here. – JNL Jul 24 '13 at 20:27
3

Traditionally, getters are prefixed with get or is for the value. This is often mentioned in java style guides. For example Java Programming Style Guide (this is just one example).

The convention for such method names is occasionally enforced in tools that use reflection or expect certain styles of code. For example, again in Java (though JSP's Expression Language), ${foo.bar} will be translated into the call foo.getBar() when the jsp is compiled. The getValue() is enforced in this way so that it becomes more than just a convention.

As mentioned, the above examples are from Java. This is a convention for Java. Other languages have other conventions that should be looked at and likely followed too. Some languages use properties (and can do other neat things with them like copy on request or read only).

Look into the style guides for your particular language choice. It is probably a good idea to follow them when possible so that other coders, when reading your code, will more quickly be able to get into the code without trying to figure out your personal style.

| improve this answer | |
2

Naming a method in a cleverly readable way has advantages. Naming methods so that their intent and nature is easy to derive from the name ("getters have prefix get, boolean predicates, is") has advantages, too.

It's up to you to strike a balance, but in a large project benefits of consistency usually outweigh those of accidental cleverness.

Renaming a method to make the name both readable and convention-conformant is a nice daily exercise. In your particular case I'd consider something like isAutoLoginEnabled or getAutoLoginFlag.

OTOH you you have a bunch of conceptually similar methods that all can follow the pattern of shouldDoSomething, your original name can be fine, too.

| improve this answer | |
  • I do like the added "Enabled" to the getter, it significantly improves the readability I find – Mike Bryant Jul 24 '13 at 15:42
1

I always find that code should be as human readable as possible. It helps to clearly define the intentions of the code. In your case think about what both the positive and negative uses of your boolean and how it would impact readability and the intentions of your logic would be.

if(!shouldAutoLogin)
{
     ....
}

versus

if(!getShouldAutoLogin)
{
    ....
}

Which gives a clearer meaning to the intention of what the code is trying to do?

As others have suggested, I would even rename the variable to

isShouldAutoLogin

or similar

| improve this answer | |
0

I tend to write getAutoLogin when I want the method to return a data type, like an int or a String. However, if I want to check if it's true or false (boolean), I simply swap the get to an is like this: getAutoLogin > isAutoLogin. I believe there is a naming convention for every language.

| improve this answer | |

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.