究竟要不要写代码注释？

看完上图你是什么反应？会骂人吗？会就对了……，代码整洁之道，是一条很漫长的路，注释是其中一部分。

若是是一个很大的方法，要不要加注释？一个大方法按照它的功能被分割成几个小方法，这样代码就比较容易阅读了，但有的童鞋说能在项目的deadline里面搞出来就好了，哪有时间整理这种大方法？为了让你的搭档或者接手者，更轻松的理解，让她/他少加班，抽时间仍是整理一下吧。按照树的结构，一个主干，其余分支都是处理不一样的逻辑。

若是是小方法能作到见名知意，就必定要见名知意，习惯老是要培养的，接一句鸡汤：走得慢并没关系，只要你坚持不停地走，那么总有一天你能走到你想要到达的地方，能超过道旁那些不敢走的人。走正道！

大牛们老是说：代码就是最好的注释。惋惜我尚未达到那个程度。可是我依然尝试着用命名代替注释，发现本身作的并不对，若是你团队的新人呢？比较复杂的方法，靠命名？因此这个时候仍是建议把注释写的清清楚楚，其一：为了本身之后维护的方便； 其二：为了其余人接手的方便。

总结一下：

• 若是本身的英语很差

对咱们来讲第一语言是中文的，英语很差状况就不同了，这就是为何国人的建议大多要求注释详尽，让代码更易读易懂；而老外的建议几乎是尽量的少；符合我国基本国情。

• 若是本身的水平还不够

对于很复杂的逻辑，务必用12345的顺序依次写清楚；对于函数中的某个参数，须要解释为何要设置这个参数，尤为是公用工具类里面的函数---说清楚参数的背景含义，可让其余调用者理解的更加清晰。

• 若是整个团队水平良莠不齐

通常不要用英文写。虽然这样看起来格调很低，但胜在你们都能轻松的看懂。写代码不能太傲娇，不能太任性，写注释也不要太傲娇，目的是让你的搭档或者接手者，更轻松的理解，提升效率，早点回家老婆孩子热炕头。

咱们不能保证每一个团队里面的每一个成员都是大神，写该写的注释，单必定要去尝试用方法名和变量名去替代注释，说不定哪一天你也成为了大神？

稍后等于永不，行动起来……