2

Possible Duplicate:
When is a Java method name too long?

I know this is probably is a question of personal opinion, but I want to know what's standard practice and what would be frowned upon.

One of my profs in university always seems to make his variable and method names as short as possible (getAmt() instead of getAmount) for instance.

I have no objection to this, but personally, I prefer to have mine a little longer if it adds descriptiveness so the person reading it won't have to check or refer to documentation.

For instance, we made a method that given a list of players, returns the player who scored the most goals. I made the method getPlayerWithMostGoals(), is this wrong? I toiled over choosing a way to make it shorter for awhile, but then I thought "why?". It gets the point across clearly and Eclipse makes it easy to autocomplete it when I type.

I'm just wondering if the short variable names are a piece of the past due to needing everything to be as small as possible to be efficient. Is this still a requirement?

Community
  • 1
  • 1
Doug Smith
  • 29,668
  • 57
  • 204
  • 388
  • 1
    You just have to weigh up the difference between readability and time required to type the name ... and make a choice. In general I see a trend towards less comments and longer "self commenting" variable and method names. – Ankur Oct 07 '12 at 03:25
  • My prof used to write sop() for System.out.println() on white board since he knows he is not going to compile it! Generally they write things in short forms.. but i feel in projects its always good to have a clear name for class variables and methods. I dont mind writing i, foo etc for local variables if thier purpose is just for loopiong or a small task. – Jayy Oct 07 '12 at 03:29
  • 5
    `boolean isThereAnythingInherentlyWrongWithLongVariableMethodNamesInJava()` – Peter Lawrey Oct 07 '12 at 07:03
  • 1
    @PeterLawrey `{return false;}` – Ruan Mendes Dec 15 '17 at 13:50

5 Answers5

13

Nothing inherently wrong, it's better to make it descriptive than cryptic. However, it's often code-smell for a method that is trying to do too much or could be refactored

Bad: getActInfPstWeek

OK: getAccountInformationForPastWeek()

Better getAccountInformation(DateRange range)

Ruan Mendes
  • 90,375
  • 31
  • 153
  • 217
9

I prefer to have long variable/method names that describe what's going on. In your case, I think getPlayerWithMostGoals() is appropriate. It bothers me when I see a short variable name like "amt" and I have to transpose that in my head (into "amount").

alfredaday
  • 2,048
  • 18
  • 14
0

Something like getAmt() is looks like C++ code style... In java usually are used more descriptive names.

Your professor made a good understandable method. But it's very popular word. It's not a general case. Use your "longWordStyle" style it's more java.

Pavel
  • 4,912
  • 7
  • 49
  • 69
0

As per standards, longer descriptive names are advised to make it more readable and maintainable on longer term. If you use very short naming e.g. a variable as a, you will forget yourself, what that variable is meant for after sometime. This becomes more problematic in bigger programs. Though I don't see an issue in using getAmt() in place of getAmount(), but definitely getPlayerWithMostGoals() is preferable over something like getPlayer().

Yogendra Singh
  • 33,927
  • 6
  • 63
  • 73
0

Long names, short names, it all depends. There are a lot of approaches and discussions but in fact a method's name should reflect its intention. This helps you to further understand the code. Take this example.

public void print(String s)

Nifty name, short, concise... isn't it? Well, actually no if there's no documentation to tell you what do you mean by "Printing". I say System.our.println is a way of printing a string but you can define printing as saving the string in a file or showing it in a dialog.

public void printInConsole(String s)

Now there are no misunderstandings. Most people can tell you that you can read the method's JavaDoc to understand it but... are you going to read a full paragraph to decide if the method you're going to use does what you need?.

IMO, methods should describe at least an action and an entity (if they're related to one). "Long" is also a perception... but really long names make the code hard to structure. It's a matter of getting the proper balance.

As a rule of thumb, I'd void abreviations and use JavaDoc to further describe a method's intention. Descriptive names can be long but the reward is both readability and a self-explainatory code.

Fritz
  • 9,987
  • 4
  • 30
  • 49