即使在今天,我经常在Java变量和方法中看到下划线,例如成员变量(如"m_count"或"_count").据我记忆,在这些情况下使用下划线被Sun称为坏风格.
他们应该使用的唯一地方是常量(比如"public final static int IS_OKAY = 1;"),因为常量应该都是大写而不是驼峰.这里,下划线应该使代码更具可读性.
你认为在Java中使用下划线是不好的风格吗?如果是这样(或不是),为什么?
如果你现在没有使用它的代码,我建议你继续这样做.如果您的代码库使用它,请继续.
编码风格最重要的是一致性.如果您没有任何要求,那么语言供应商的建议可能是一个很好的起点.
sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs(); as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();
规则:
执行您正在编辑的代码
如果#1不适用,请使用camelCase,不要使用下划线
我不认为使用_或m_来表示成员变量在Java或任何其他语言中是不好的.我认为它提高了代码的可读性,因为它允许您查看片段并快速识别本地的所有成员变量.
您也可以通过强制用户使用"this"来预先添加实例变量来实现这一点,但我发现这是非常严厉的.在许多方面,它违反了DRY,因为它是一个实例变量,为什么要对它进行两次限定.
我个人的风格是使用m_而不是_.原因是还存在全局变量和静态变量.m _/_的优点是区分变量范围.因此,您不能将_重用于全局或静态,而是分别选择g_和s_.
"糟糕的风格"是非常主观的.如果某些约定适用于您和您的团队,我认为这将符合一个糟糕/好的风格.
回答你的问题:我使用前导下划线来标记私有变量.我发现它很清楚,我可以快速扫描代码并找出发生了什么.
(我几乎从不使用"这个",除了防止名字冲突.)
在变量前面使用'm_'或'_'可以更容易地在整个对象的方法中发现成员变量.
输入"m_"或"_"这样的副作用将使intellsense首先弹出它们;)
我碰巧喜欢(私有)实例变量的前导下划线,它似乎更容易阅读和区分.当然这件事可以让你遇到边缘情况的麻烦(例如公共实例变量(不常见,我知道) - 无论你怎么称呼他们可能会破坏你的命名惯例:
private int _my_int;
public int myInt;? _my_int? )
- 尽管我喜欢这种风格并且认为它是可读的我发现它可能比它的价值更麻烦,因为它不常见并且它可能与您正在使用的代码库中的任何其他内容不匹配.
- 自动代码生成(例如eclipse的生成getter,setter)不太可能理解这一点,因此你必须手动修复它或者使用eclipse进行修复以使其识别.
最终,你要反对其余的(java)世界的首选,并可能会有一些烦恼.正如之前的海报所提到的,代码库的一致性胜过上述所有问题.
在过去,使用下划线被认为是不好的风格是有原因的。当运行编译器负担不起的费用,并且监视器配备了惊人的320x240像素分辨率时,通常很难区分_name
和__name
。