书本上的理论以前的笔记里还记着这些理论呢。《重构-改善既有代码的设计》任何一个傻瓜都能写出计算机可以理解的代码唯有写出人类容易理解的代码才是优秀的程序员。《代码整洁之道》上的言论什么是整洁的代码1.我喜欢优雅和高效的代码。代码逻辑应当直截了当令缺陷难以隐藏尽量减少依赖关系使之便于维护依据某种分层战略完善错误处理代码性能调至最优省得引诱别人做没规矩的优化搞出一些混乱来。整洁的代码只做好一件事。2.整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图充满了干净利落的抽象和直截了当的控制语句。3.整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。4.如果每个例程都让你感到深合己意那就是整洁代码。如果代码让编程语言看起来是专为解决那个问题而存在的就可以称之为漂亮的代码。有意义的命名变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你它为什么存在、它做什么事、应该怎么用。如果名称需要用注释来补充那就不算是名副其实。以前看这些东西看的是津津有味觉得说的很对。包括以前的公司也宣传这种规范说起变量名之前要思考一下尽量少些注释。国内的实际情况关于前面提到的书籍上的规范性理论我的体会是这些书都是外国人写的编程语言是他们发明的他们的母语也是英语所以他们在写代码的时候追求代码的强语义性的收益很高不管用啥单词他们一看就懂再考虑下命名与业务的契合度就很完美他们看代码那真就像看”散文“一样了。但是国内的实际情况是什么开发人员写代码碰到不知道怎么命名的单词都是随手翻译一下就写上去了不管这单词认不认识或者生僻与否还有很多拼写错误也不纠正再加上代码逻辑不够清晰的话那给人的阅读体验当然不好那什么“山”就来了。再说说有些公司为什么提倡不写注释要用命名体现意图。这些都是老一辈程序员有情怀且带的都是小团队而且业务语言和开发语言都比较统一所以代码名字写准确了基本就能很好的理解业务。但是大公司就不行了一个组十几个人时间紧任务重有些领导甚至没时间review代码或者根本不在乎你写的啥功能实现就行了所以也没人在乎这些规范了。加上张三的任务李四也不一定了解再不写点注释那接手的人痛苦至极。总结所以必要时要尽量多写的代码注释把逻辑描述清楚利己利人。当然这并不意味着可以随便命名了。注释要能帮助梳理整体逻辑必要的不能省不能自我感觉良好看着自己的干净的代码心里美滋滋也许很快就忘了。非必要时就不要写注释了有的人可能待过特殊的公司每一行代码都写注释像什么list.get(0)true或者false都写个注释那也实在没必要。最后我觉得阿里开发手册里关于注释规范说的挺好贴一下