如何去评价一个代码写的是否好坏,这往往是按照评价者的主观思想去评价的,那么什么是具体的好代码,什么又是坏代码呢?
那么可以对一份代码,按照如下的描述方式去评价
灵活性（flexibility）、可扩展性（extensibility）、可维护性（maintainability）、可读性（readability）、可理解性（understandability）、易修改性（changeability）、可复用（reusability）、可测试性（testability）、模块化（modularity）、高内聚低耦合（high cohesion loose coupling）、高效（high effciency）、高性能（high performance）、安全性（security）、兼容性（compatibility）、易用性（usability）、整洁（clean）、清晰（clarity）、简单（simple）、直接（straightforward）、少即是多（less code is more）、文档详尽（well-documented）、分层清晰（well-layered）、正确性（correctness、bug free）、健壮性（robustness）、鲁棒性（robustness）、可用性（reliability）、可伸缩性（scalability）、稳定性（stability）、优雅（elegant）、好（good）、坏（bad）……
这些词汇所代表的的具体含义是什么,是这篇文章的重点
很多评价标准之间,是具有耦合性的,这就比如说
一份代码的可读性好,可扩展性好,就以为这可维护性好,而且各个评价标准并不是非黑即白的,也就是说,这是有一个限度来决定
常见的评价标准有:
1.可维护性
什么是可维护性,落实到编码开发,无外乎就是修改bug,修改老的代码,添加新的代码之类的工作,所谓代码易维护,就是不破坏原有的代码基础上,添加新的代码之类的,所谓不易维护,就是不容易去添加代码,或者冒着很大的风险去引入新代码,而且代码的易维护,还由着其他因素来决定的,比如一个代码的可读性好,那么也可以说易维护,一份代码如果分层清晰,模块化高,高内聚低耦合,遵从基本接口而非实现编程的设计原则
从侧面来说,如果一个接口添加功能轻松完成,那么就可以说是易维护的,反之,添加困难,就是不易维护的
2.可读性
一句话 “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
任何人都能写出机器识别的代码,但是好程序员能写出别人能懂的代码
代码的可读性是评价代码质量的重要标准之一,在编写代码的时候,是否容易理解,是容易维护的标准之一,那么这个标准可以取决于代码的命名是否规范,符合编码规范,注释是否详解,函数长度是否合适,是否清晰划分代码块
3.可扩展性
可扩展性,是一份代码是否良好的重要标准,应对了未来需求变化的能力,和可读性一样,是否容易扩展决定是否容易维护,也就是在不修改或者少量修改原有代码的情况下,通过扩展来添加新的功能代码,如果一份代码已经预留了一些扩展点,那么就可以说是具有良好扩展性的
4.灵活性
灵活性是描述代码指令的常用指令,怎么说是灵活呢,
在添加一个新的功能代码的时候,在原有基础上已经预留了坑位,就是具有灵活性的
实现一个功能的时候,原有代码上预留好了扩展点,就是具有灵活性的
使用某组接口的时候,可以应对多种场景,可以说是具有良好灵活性的
5.简洁性
Keep it Simple,Stupid,就是尽量保持代码简单,逻辑清晰,易读易维护,一个我经常犯的问题,就是经常喜欢在项目中引入一些复杂的设计模式,来彰显自己的水平,往往导致可读性底,使用最简单的方式来解决最复杂的方法,是编程老手该干的
6.可复用性
代码的可复用性可以理解为,尽量减少重复代码的编写,复用自己已经有的代码,也就是可复用性,在Java中,继承,多态,就是为了提高可复用性而准备的,而且可复用性和DRY原则紧密接结合
7.可测试性
可测试性是一个很重要的环境,一个代码的可测试性差,比较难以书写单元测试,就说明代码本身设计有问题,代码的可测试性是非常重要的环境
那么如何书写出高质量的代码,就需要输出的代码尽可能的高质量,符合上面的标准
如果想要输出符合上面标准的代码,就需要掌握一些更加细节的规范,面向对象思想等,设计原则,设计模式,为了输出更加高质量的代码
还有什么代码评价标准非常重要的呢?
我认为,机器性能利用是非常重要的一个环节,如果浪费了大量机器性能,导致的性能低下,也是不应该出现的
代码的具体行数,也是一个评判的标准
最后
代码的黄色warning的减少出现,是一个重要标准
在开发过程中,像是使用Idea或者Eclipse时候,减少出现的黄色警告,也是重要的一环.即为,减少使用不确定的类型,避免使用过期的类或者方法