2

重複の可能性:
Java メソッド名が長すぎるのはいつですか?

これはおそらく個人的な意見の問題であることはわかっていますが、何が標準的な慣行であり、何が嫌われているのかを知りたい.

たとえば、大学の私の教授の 1 人は、変数名とメソッド名をできるだけ短くするようです (getAmount ではなく getAmt())。

私はこれに異議はありませんが、個人的には、それを読んでいる人がドキュメントを確認したり参照したりする必要がないように、説明を追加する場合はもう少し長くしたいと思います.

たとえば、プレイヤーのリストを指定すると、最も多くのゴールを決めたプレイヤーを返すメソッドを作成しました。メソッドを作成しましたgetPlayerWithMostGoals()が、これは間違っていますか? どうにかして短くしようとしばらく悩んだのですが、「なぜだろう？」と思いました。要点が明確に伝わり、Eclipse を使用すると、入力時に簡単にオートコンプリートできます。

効率的にするためにすべてをできるだけ小さくする必要があるため、短い変数名が過去のものであるかどうか疑問に思っています。これはまだ要件ですか？

4

5 に答える 5

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)

于 2012-10-07T03:39:12.840 に答える
8

私は、何が起こっているかを説明する長い変数/メソッド名を使用することを好みます。あなたの場合、 getPlayerWithMostGoals() が適切だと思います。「amt」のような短い変数名を見ると気になり、それを頭の中で (「金額」に) 転置しなければなりません。

于 2012-10-07T03:29:43.250 に答える
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.

于 2012-10-07T03:36:00.700 に答える
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().

于 2012-10-07T03:36:05.473 に答える
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.

于 2012-10-07T03:37:52.930 に答える