好的代码，就像是好的笑话——无需解释就能让别人明白。如果你的代码能够做到不解自明，在大多数时候，你根本无需为其配备说明文档。
好的代码，就像是一辆配备了优秀音响和杯架的汽车，这辆车在行驶到最高速度的时候，你听不到噪音，也不用担心水会洒出来。在它出现故障的时候，任何一名修理工都可以使用最常见的工具，在最短的时间里轻松将其修好。
而坏的代码，就像是一辆向你承诺最高速度可以达到200MPH，但是音响只能播放老式的磁带，而且杯架还不稳的车。你在调整反光镜角度的时候，汽车都会突然出现故障，而且一般的修理工还修不了这辆车，必须要找专家，让专家在生产线上使用专业的工具来修理。
好代码像是一本写作技巧高超的人所写的书
1.容易理解
2.分章明确，每一章都有清晰的主旨
1.容易理解
2.分章明确，每一章都有清晰的主旨
1.各个章节之间纷乱复杂，每一章都没有明确的主旨
2.连篇累牍的重复一句话，而且毫无缘由
3.作者在一开始设定了一些规则，但是在后面的内容中却自己不断的违反这些规则
4.突然间书里出现了一个吸血鬼，而且还能在白天出来吸血。
1.各个章节之间纷乱复杂，每一章都没有明确的主旨
2.连篇累牍的重复一句话，而且毫无缘由
3.作者在一开始设定了一些规则，但是在后面的内容中却自己不断的违反这些规则
展开全文
4.突然间书里出现了一个吸血鬼，而且还能在白天出来吸血。
可读性——不只是你，还有你身边与你合作的其他开发者
可维护性——让你的代码在修改的时候很简单
简洁性——不要让你的代码看上去毫无必要的复杂
效率性——尽可能的让你的代码获得最快的运行速度
明确性——如果你的代码能够做到不解自明，在大多数时候，你根本无需为其配备说明文档。在为方法和属性命名的时候，做到尽可能的合理。把长的代码进行拆分。不要复制/粘贴代码块。
如果你的同事不能轻松的看懂你写的代码，那么你的代码就不够好。
代码质量测试
1.找一个从来没读过你的代码的开发者，让他看你的代码，并且让他试着说出每一个模块的作用。
2.如果你经常需要向他进行解释，那么说明你的代码不够好。解释的次数越多，代码的质量就越低。
3.如果你只是静静的坐在一边，他无需问你任何问题，那说明你的代码质量很高。
1.找一个从来没读过你的代码的开发者，让他看你的代码，并且让他试着说出每一个模块的作用。
2.如果你经常需要向他进行解释，那么说明你的代码不够好。解释的次数越多，代码的质量就越低。
3.如果你只是静静的坐在一边，他无需问你任何问题，那说明你的代码质量很高。
代码写的很聪明，但是又不会过分的聪明
无论在速度上，还是可读性上，你都使用了最佳的算法
类、变量和函数都得到了正确的命名，让人看一眼就能理解
休息了一个周末之后，你继续写代码，发现自己可以立刻继续之前的工作
那些需要重复使用的东西总是可用
你所使用的方法都很短，最理想的情况下要少于50行，最多不超过100行而且能够完美的执行单个任务
在调用方法的时候，你有着足够的信息，无需在代码堆中苦苦寻找
能够很轻松的在此前的代码中进行功能添加和修改
try/catch块的体量尽可能的小
毫不费力的就可以写出单元测试
代码写的很聪明，但是又不会过分的聪明
无论在速度上，还是可读性上，你都使用了最佳的算法
类、变量和函数都得到了正确的命名，让人看一眼就能理解
休息了一个周末之后，你继续写代码，发现自己可以立刻继续之前的工作
那些需要重复使用的东西总是可用
你所使用的方法都很短，最理想的情况下要少于50行，最多不超过100行而且能够完美的执行单个任务
在调用方法的时候，你有着足够的信息，无需在代码堆中苦苦寻找
能够很轻松的在此前的代码中进行功能添加和修改
try/catch块的体量尽可能的小
毫不费力的就可以写出单元测试
假设你的项目中有三个不同的层——内层、中层和外层。你的内容不应该从中层和外层那里导入任何东西。中层不应该从外层导入任何东西 ，这样做的好处是，你可以对代码的内层进行独立测试。
“好的代码本身就是最好的说明文档。” — Steve McConnell