究竟怎样写代码才算是好代码

今天让我们来谈谈代码吧。代码重要吗？固然，代码就是设计（Jack W.Reeves, 1992）；代码是最有价值的交付物。我们需要好代码吗？在给“好代码”下个定义之前，这个问题没法回答。那末，究竟甚么是好代码？

看下面这段英文解释：

‘Good code’ is code that works, is bug free, and is readable and maintainable. Some organizations have coding ‘standards’ that all developers are supposed to adhere to, but everyone has different ideas about what’s best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. ‘Peer reviews’, ‘buddy checks’ code analysis tools, etc. can be used to check for problems and enforce standards.

解释以下：

好的代码是代码运行正常、bug很少、并且具有可读性和可保护性。1些企业自己有所有开发人员都必须遵照的编码规范，但是对甚么样的代码是最好的每一个人的都有自己的标准、或有太多的或太少的编码规则。这有多种原则和标准，例如，McCable 的复杂度度量。的确使用过量的编码标准和规则可能下降生产率和创造性。“同行评审”或“同事检查”代码分析工具等，都能用来检查问题或坚持标准。

那末接下来我们深入介绍下，甚么是好代码的标准呢，请看下面解释：

1、代码命名规范：

1、 package包名全部由小写的ASCII字母组成，用“.”分隔。在此项目中，所有的包均以“com.abc.ticket”开头。

2、 class 类名应当是名词，每一个内部单词的头1个字母大写。应当使你的类名简单和具有说明性。用完全的英语单词或约定俗成的简写命名类名。
【示例】public class UserManager

3、 interface接口名应当是名词，每一个内部单词的头1个字母大写。应当使你的接口名简单和具有说明性。用完全的英语单词或约定俗成的简写命名接口名。
【示例】interface TicketManagement

4、 Class 成员属性及变量的命名 (*) 变量名全部由字母组成，头1个字母小写，以后每一个内部单词的头1个字母大写。变量名应当短而成心义。变量名的选择应当易于记忆。1个字符的变量名应避免，除非用于临时变量。通常临时变量名的命名规则为：i，j，k，m，n用于整数；c，d，e用于字符。

5、常量的命名，Java 里的常量，是用static final 修饰的，应当用全大写加下划线命名，并且尽可能指出完全含义。
【示例】static final String SMTH_BBS=”bbs.tsinghua.edu.cn”; 

6、数组的命名，数组应当总是用下面的情势来命名：byte[] buffer; 

7、方法的参数和变量的命名规范1致，且应使用成心义的参数命名，如果可能的话，使用和要赋值的字段1样的名字。
【示例】setCounter(int size){ this.size = size; } 

8、 方法命名(*)方法的命名应当使用动词，头1个字母小写，以后每一个内部单词的头1个字母大写。在方法名的选择上应意义明确便于记忆。对属性的存取方法，应使用getXXX()和setXXX()名称，以isXXX()，hasXXX()来命名返回值为boolean 类型的方法。

以上几条如果符合就算是好代码了吗？固然不是，这只是代码中最基本的命名规范而已，就算不符合最多就是代码不好看，没甚么其他影响。

2、代码逻辑规范

1、需求、设计中的重点功能（结合需求/设计的评审产出）

2、代码格式校验
action/façade等系统入口是不是有数据格式校验
需要存入数据库的数据字段是不是有长度校验

3、分支/循环
if-else/switch是不是处理了所有分支
分支的条件语句是不是有“副作用”；即，条件语句是不是会改变系统状态/数据等
循环边界是不是覆盖了所有元素
是不是有死循环等

4、异常处理
是不是有“吃掉异常”的情况
是不是记录了异常日志
如果2次抛出，是不是有公道的异常层次/结构
如果内部处理，对异常的处理是不是能保证后续代码正常运行

5、单元测试
是不是有单元测试
单元测试是不是自动化
单元测试是不是能完全覆盖需求

6、 事务处理
事务范围是不是公道；或说，是不是把没必要要的操作放到了同1个事务中
事务传播方式是不是公道（required，never，new等配置）

7、sql语句
sql语句是不是正确
使用mybatis的动态语句时，是不是有潜伏的sql语法问题

8、第3方组件
使用Redis，RabbitMQ等组件，是不是真的对组件完全了解，在使用的进程中是不是正确履行了开启与关闭操作。

写到这里，可能会有很多读者认为，代码规范也就这些了吧，依照上面2类写完算是优秀的代码了吗？其实还是远远不够。

3、可读性，可保护性

曾看过1段代码，1个method几千行代码，所有业务逻辑都揉在了1起。然后没有人愿意再保护了，修改1点就会引发不可预知的毛病，代码又臭又长。在这类情况只能重构，因而我在部门内部推行2本书《代码整洁之道》和《重构-改良既有代码的设计》并且制定部门自己的开发风格，通过组织所有开发人员练习小项目的开发，使全部部门的开发风格整齐划1，不论是老同事还是新同事，都能够非常快速的上手，程序中依赖度下降，结构非常清晰。

4、性能瓶颈

在真实工作中，很多程序员其实在开发完程序后不去真正关注程序的性能和响应时间到底如何，凭的是以往开发经验在开发的进程中尽量的去减少问题点。

这样就只能在生产环境中去验证性能问题了，实际这类做法风险较大，所带来的损失也是较大的，我们在开发完程序后，不但要采取Junit或JMock这样的工具进行业务功能自测，更重要是能够采取相应的工具和命令进行代码性能和响应时间的测试，在第1关就可以够找出可能出现的1部份问题点，那末常常使用的工具和命令以下：
top，vmstat，pidstat，Hprof，Btrace，Dtrace等命令。

具体可以参考我之前写过的文章2篇：
http://blog.csdn.net/u013970991/article/details/52035153
http://blog.csdn.net/u013970991/article/details/52035133

5、代码容错

• 曾有1个案例：
  X同事在“统1配置管理系统“中将1个参数配置在里面，当参数进行修改的时候相应的程序会马上做出改变进行相应逻辑调剂，可是另外一个A同事在操作这个系统的时候配错了参数，这时候候系统在生产环境中就开始报错，以致于利用程序崩溃，逻辑没法进行下去造成较严重的生产事故，最后恢复完参数故障时间已进行了10几分钟。针对这个问题当时产生了争辩，究竟是配置人员的错，还是开发人员的错。

其实在我看来，究竟是谁的问题暂且放在1边，关键是开发人员是不是在写程序的进程中有无多1丝的思考，多斟酌1些问题点，程序员要时刻怀着1颗怀疑的心和畏敬的心对待自己写的程序，像上面的问题我们完全可以做1些异常捕获和默许设置，在出错的时候最少能够让利用程序跑下去而不能整体报错，让用户没法继续使用。

• 再说1个案例：
  某部门在开发“统1配置管理系统”，使用的是Zookeeper组件，而且它的工作原理是当某节点改变的时候，主动去通知所注册的系统，但是有个条件是如果那些系统，有1部份没有得到通知，有1部份得到了通知该怎样办，比如某几个系统在通知的时候正好在重启，这时候候zookeeper就不能通知到相应的系统，因而在使用该“统1配置管理系统”的时候，出了生产事故。

其实还应当再重复说1下，程序员应当持有怀疑的精神面对调用的系统和被调用的系统，不要把稳定、安全、可靠寄托于他人身上。

究竟怎样写代码才能算好代码？这是1个有争议的话题，每一个人的理解可能都不同，关键是通过讨论这个话题制定1个符合自己部门要求的规范，这样有根据的代码才可能成为好的代码。