方法参数名称是否应该在名称中指定其单位？
在以下两个具有单位和值的方法参数名称选项中，您更喜欢哪一个，为什么？ （我使用过 Java 语法，但我的问题适用于大多数语言。）
public void move(int length)
或
public void move(int lengthInMetres)
选项 (1) 似乎就足够了，但我发现当我编码/打字时，我的 IDE 可以向我指示我需要一个长度值，但我通常必须打破步幅并查找方法的 doco 来确定单位，以便我传递正确的值（例如不是公里而不是米）。这可能会扰乱思维过程。选项 (2) 缓解了这个问题，但可能很冗长，特别是如果您的单位是 metresPerSecondSquared 或类似的单位。您认为哪个最好？
Of the following two options for method parameter names that have a unit as well as a value, which do you prefer and why? (I've used Java syntax, but my question would apply to most languages.)
public void move(int length)
or
public void move(int lengthInMetres)
Option (1) would seem to be sufficient, but I find that when I'm coding/typing, my IDE can indicate to me I need a length value, but I typically have to break stride and look up the method's doco to determine the units, so that I pass in the correct value (and not kilometres instead of metres for example). This can be an annoying interruption to a thought process. Option (2) alleviates this problem, but can be verbose, particularly if your unit is metresPerSecondSquared or some such. Which do you think is the best?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您的参数（和方法）名称尽可能清晰，即使它们变得冗长。当您在 6 个月内查看或使用该代码时，或者当其他人必须查看您的代码时，您会很高兴。
如果您认为名称变得太长，请考虑重新措辞。在您的示例中，您可以使用可能足够清晰的参数名称
int Metres。考虑更改方法名称，例如public void moveMetres(int length)。在 Visual Studio 中，当您在其他位置使用该方法时，在方法定义上方输入 3 个注释符号时生成的 XML 注释将出现在 Intellisense 提示中。其他 IDE 可能具有类似的功能。
应谨慎使用缩写。如果绝对必要，仅使用众所周知的和/或相关行业标准缩写并保持一致，即各处使用相同的缩写。
退一步。编写代码，然后继续处理其他事情。第二天回来检查一下名字是否还清晰。
同行评审也有帮助。如果您的命名方案足够清晰或有助于集体讨论替代方案，请询问了解编程语言（或只是逻辑思考）但不了解具体功能的人。他们可能是将来必须维护你的代码的可怜的傻瓜！
I would recommend making your parameter (and method) names as clear as possible, even if they become wordy. You'll be glad when you look at or use the code in 6 months time, or when someone else has to look at your code.
If you think the names are becoming too long, consider rewording them. In your example you could use parameter name
int Metresthat would probably be clear enough. Consider changing the method name, egpublic void moveMetres(int length).In Visual Studio, the XML comments generated when you enter 3 comment symbols above a method definition will appear in Intellisense hints when you use the method in other locations. Other IDEs may have similar functionality.
Abbreviations should be used sparingly. If absolutely necessary only use commonly known and/or relevant industry-standard abbreviations and be consistent, ie use the same abbreviation everywhere.
Take a step back. Write the code then move on to something else. Come back the next day and check to see if the names are still clear.
Peer reviews can help too. Ask someone who knows the programming language (or just thinks logically), but not the specific functionality, if your naming scheme is clear enough or to help brainstorm alternatives. They might be the poor sap who has to maintain your code in the future!
我更喜欢第二种方法（即 lengthInMeters），因为它准确地描述了该方法所需的输入。事实上，当您刚刚编写代码时，您会发现弄清楚单位很混乱，这意味着当您（或某人）稍后查看同一段代码时，会更加混乱。关于变量名称较长的问题，您可以找到缩写它的方法（例如“mtrsPerSecondSquared”）。
同样在防御第二种方法中，Code Complete一书提到了一项研究，该研究表明，在以下情况下调试程序所需的工作量被最小化：变量的名称平均为 10 到 16 个字符。
I would prefer the second approach (i.e. lengthInMeters) as it describes the input needed for the method accurately. The fact that you find it confusing to figure out the units when you are just writing the code would imply it would be much more confusing when you (or some one) looks at the same piece of code later. As regard to issue of the variable name being longer you can find ways to abbreviate it (say "mtrsPerSecondSquared").
Also in defence second approach, the book Code Complete mentions a research that indicates, effort required to debug a program was minimized when variables had names averaged to 10 to 16 characters.