我在C++和Java中的一个令人讨厌的(？)编程习惯是始终在调用或访问成员之前使用this.例如:this.process(this.event).
我的一些学生评论了这一点,我想知道我是否在教习坏习惯.
我的理由是:
使代码更具可读性 - 更容易区分字段和局部变量.
使标准调用与静态调用(尤其是Java)区分开来更容易
让我记住,这个调用(除非目标是最终的)可能最终会出现在另一个目标上,例如在子类中的覆盖版本中.
显然,这对编译的程序没有任何影响,只是可读性.那么我是否或多或少可读？
注意:因为确实没有正确答案,我把它变成了CW.
我认为它的可读性较差,特别是在字段的突出显示与局部变量不同的环境中.我想要看到"这个"的唯一时间是需要时,例如:
this.fieldName = fieldName
分配字段时.
也就是说,如果由于某种原因需要某种方法来区分字段,我更喜欢"this.fieldName"到其他约定,例如"m_fieldName"或"_fieldName"
这是一个非常主观的事情.Microsoft StyleCop有一个规则需要这个.限定符(虽然它与C#相关).有些人使用下划线,有些人使用古怪的匈牙利符号.我个人对此有资格.即使没有明确要求避免混淆,因为有些情况下它可以使一个人的代码更具可读性.
您可能还想看看这个问题:
您对成员变量使用什么样的前缀？
在我加入现任雇主之前,我从未见过这种风格.我第一次看到它时,我认为"这个白痴根本不知道,Java/OO语言通常不是他的强项",但事实证明,这是一个经常发生的痛苦,并且是几个项目的强制性风格,尽管这些项目也使用了
if (0 == someValue)
{
....
}
做条件的方法,即将常数放在测试中,这样你就不会冒写作的风险
if (someValue = 0)
意外 - 忽略编译器警告的C编码员的常见问题.事实上,在Java中,上面只是无效的代码,并且会被编译器抛弃,所以他们实际上使他们的代码不那么直观,没有任何好处.
因此,对于我来说,远远没有表明"作者正在用专门的思考过程进行编码",这些事情让我觉得更有可能来自那种只是坚持别人告诉他们的规则而没有质疑或知道的人首先是规则的原因(因此规则不适用的地方).
我听到的原因主要归结为"这是最佳实践",通常引用Josh Bloch的Effective Java,这在这里有很大的影响力.事实上,Bloch甚至没有使用它,即使我认为他可能应该提供可读性!再一次,似乎更多的是那些被告知要做的人并且不知道为什么这样做的事情!
就个人而言,我更倾向于同意Bruce Eckel在Thinking in Java(第3版和第4版)中所说的内容:
"有些人会痴迷于把它放在每个方法调用和字段引用之前,认为它使它"更清晰,更明确".不要这样做.我们使用高级语言是有原因的:他们为我们做事.如果你把这个中时,它不是必需的,你会混淆视听,惹恼大家谁读你的代码,因为他们已经阅读代码的所有其余的将不使用这个无处不在.人们期望这种使用只有当它是必要的.遵循一致和直接的编码风格可以节省时间和金钱.
脚注,第169页,思考Java,第4版
相当.少即是多,人.
3个理由 (Nomex适合ON)
1)标准化
2)可读性
3)IDE
1)biggie 不是Sun Java代码风格的一部分.
(不需要Java的任何其他样式.)
所以不要这样做(在Java中.)
这是蓝领Java事物的一部分:到处都是一样的.
2)可读性
如果你想要这个.在每个this.the this.word之前都有这个.你真的这么认为它改善了这个可读性吗？
如果一个类中有太多的方法或变量让你知道它是否是成员...重构.
你只拥有成员变量和你没有在Java中的全局变量或函数.(在其他语言中,你可以有指针,数组溢出,未经检查的异常和全局变量;享受.)
如果你想知道方法是否在你的类父类中...记得在声明上放置@Override并让编译器告诉你是否没有正确覆盖.如果要调用父方法,则super.xxxx()是Java中的标准样式,否则将其保留.
3)IDE 任何编写没有理解语言的IDE并在侧边栏上给出轮廓的代码的人都可以在自己的镍上编写代码.意识到如果它不是语言敏感的话,你就会被困在1950年代.没有GUI:被困在50年代.
任何体面的IDE或编辑器都会告诉你函数/变量的来源.即使是最初的VI(<64kb)也可以用CTags做到这一点.目前只是没有理由使用蹩脚的工具.好的是免费赠送的!
有时我喜欢写这样的课程:
class SomeClass{
int x;
int y;
SomeClass(int x, int y){
this.x = x
this.y = y
}
}
这样可以更容易地判断哪个参数设置了哪个成员.
我认为更具可读性.出于同样的原因,我按照你的方式做到了.
我发现越少越好.你的代码中有更多不必要的冗长垃圾,人们维护它的问题就越多.也就是说,具有清晰一致的行为也很重要.
京公网安备 11010802040832号 | 京ICP备19059560号-6 