基本的规范和约束(一)

一些基本的规范和约束，几乎每个团队都会有一套自己的准则，一方面统一标准，增加可读性，便于相互间协作开发。另一方面也方便团队成员离职后出现bug，后来者也能更快的去定位并解决问题，降低维护成本，提高工作效率，可维护性大大提升。杂乱无章的代码实现一个大功能，让自己看了都嫌弃的代码，对于后来者去维护，无疑会亲切的问候各路祖宗。一个好的编码习惯，属于一个合格程序员的自我修养，于己于人，百利而无一害。

命名的规范

对于开发中的规范和约束，首当其冲要说的就是命名，这近五年的工作中，和稂莠不齐的人合作过，记得最多的时候，我曾同时期开发和维护五个项目，业余时间，也曾和各路英雄好汉互相合作、互相学习和共同进步。在这个过程中，经常帮一些朋友改一些bug，或者协作完成一些项目，最让我觉得头疼的就是一些不规范的命名，不规范的样式有很多，各种奇怪的命名都有。我曾看到过这样一串命名，其中有两个功能，一个叫做专栏详情，一个叫做专栏留言，命名却是“ZhuanLaiDetalActivity”和“ZhuanLaiLiuYanActivity”，看的我很懵。

这样的命名，就问你怕不怕！对于这样的命名都怕了，那真没见过世面，这个至少还能看出个大概，说实话，如果从可读的角度来说的话，其实这样的命名还好的，正常情况下，这样的命名我还是可以直接阅读的，之前看到过一些汉语拼音的缩写，比如动检证命名为djz，这个看起来才更懵了，而类似这样的命名，现实中却有很多，我之前在反编译WeChat的时候，甚至也看到一些不规范的命名，具体忘记了，有兴趣的可以自己去看下。

对于拼音命名，这里说一点不知道会不会被喷，遇到过一些朋友总是喜欢拼音命名，汉语拼音是中华民族推动汉文化的伟大创举，但是在编程的时候用拼音，真的觉得好low，即使再牛逼的技术作支撑，写出来的代码也像小学生的作品，这里没有看不起汉语拼音的意思，只是发表下内心的一些想法。

建议：大驼峰、小驼峰或者下划线命名都可以，如果没有一个统一的标准，可以参考《阿里巴巴Java开发手册》，对于刚入行的朋友，更应该从命名抓起，对于以后的成长有很大的帮助。

开发手册下载地址：https://pan.baidu.com/s/1mjZxvSW

注释必要性的分析

除了命名外，我觉得注释的重要性可以排到第二的位置，很多人都觉得注释写得越多越好，之前在一些书里和视频里都看到提倡多写注释，甚至有些视频里的讲师提倡超过三分之一的注释，对于新手来说，更多地注视可以起到笔记的作用，这个可以理解，而对于源码中的注释，这是面对整个开发者，这些也都是很有必要的。

但是有些注释的增加，却给我们增加了很多负担和误解，在上次的review的时候发现，有的同事copy我的一些代码的时候，其实是想做另一个功能，只是想把一些代码拷贝过去然后大修改（我不喜欢重复造轮子，对于相似的一些功能，最好做的灵活一点，提高代码的可重用性和灵活性），其实可以重用的地方很少，搞不明白为啥不自己写那么几行代码，这都不是事，让我很懵逼的是他们把我的备注和作者也拷贝过去了，当我进入那个类的时候，发现作者是我，去git查看历史提交，完全没我啥事，而且功能描述和此类完全不相关…

上述的错误注释并没有影响日常开发，而有时候，一个方法经过版本的迭代后，已经不是实现之前的功能，注释没有改过来，这往往会给维护带来一些不必要的麻烦。

对于注释，还有一点要说的就是一些多余的注释，这个叫需要和命名相结合，好的命名规范，可以省略好多不必要注释，比如login、register，再加上登录、注册的注释，完全没必要，良好的习惯，可以给我们开发带来很多便捷，但有些喜欢textview1、textview2命名的，这些就算加了注释，等下文用到的时候，看了也是一群羊驼在奔跑，上下奔腾的那种。

    for (int i = 0; i < j; i++) {        // TODO    }

对于这样的代码，在平时开发还有看网上demo的时候都是很常见的，甚至可以说是编程中最常见的代码之一，对于这种模糊命名，可能很多人会觉得很正常，是的，确实很常见，也会有部分人会把责任归咎于谭浩强老师，是的，谭老的书中问题确实很多，但这不是写这种代码的理由，日常开发中，还有平时维护别人代码的同时，总会去调试for语句，难道不觉得这样的代码很糟糕，看得有点懵吗？就算加了注释，还是一坨一坨的，这个i到底是啥，到底想进行什么操作，至少从这里看不出来。

建议：合理使用注释，对于新手在学习期间，在陌生的代码和不清晰的逻辑上，尽可能多一点注释，便于理解，对于老鸟，尽可能规范的命名，通过命名达到注释的效果，但是对于逻辑复杂或者操作状态太多的时候，必要的注释还是很重要的，减小维护成本。

case的规范

今天打算写到case后的错误使用，就去公司项目中找，还真让我找到了，也是醉了，刚刚和相关同事打过招呼，目前在修改中。

对于这样的代码，最大的不好就是可维护性太差，可读性太差，我们有个页面，有几十种状态，如果用这样方式写下去，这压根没法维护。
建议：合理使用常量去替代case后面的值，比如SUBMIT_LOGIN来替换1、2、3、4、5的常量，增加可阅读性和可维护性，这在handler中也是经常被滥用，希望新手能引起注意。

代码可重用性的一点建议

对于这样一串代码，如果一眼不能看出至少三个问题，可以去培训机构继续深造了，哈哈，先不说常量的滥用，和上一条case后的滥用有同一个毛病，目前只说代码的可重用性。

这是通过一次次迭代后的结果，但这不是借口，我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计软件的可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。就目前代码来说，{}中的代码不是几乎一样，是完全一样，对于平时开发过程中，如果同样的代码写了两遍或者两遍以上，就应该考虑提取了。这个还是聚合在一起的代码，平时开发中，就算是不同的类用到类似的代码，也应该去考虑提取复用，而不是一次又一次的去复制、重写，这是完全没必要的换习惯。

建议：提取和封装也是一种能力，合理的提取和封装，使代码看起来更简洁，可读性更好。

先整理一点点，后续还会继续整理，目前，布局方面还没开始写，下一篇写布局方面的一些建议。

微信扫我