我们一般从可维护性、可读性、可扩展性、可测试性、可复用性、简洁性来评价代码的质量。

可维护性

所谓维护无外乎就是修改bug、修改老的代码、添加新的代码之类的工作。代码易维护指的是在不破坏原有代码设计、不引入新的bug的前提下，能够快速的修改或者添加代码。那么代码不易维护就指的是修改或者添加代码，有极大的风险会引入新的bug或者需要花费很长时间才能完成。
我们知道代码的维护时间，要远远高于代码的编写时间。工程师的大部分时间可能都是花费在修修bug、改改老的功能逻辑、添加一些新的功能逻辑之类的工作。为此如何编写一个易于维护的代码格外重要。
代码的可维护性由很多因素协同作用的结果。代码的可读性好、可扩展性好、简洁就会使得代码的可维护性好。更具体的，如果代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等，那就意味着代码易维护。此外代码的易维护性还跟项目代码量、利用的技术的复杂程度、文档是否全面、团队人员的水平相关。
从上面可以看出，从正面判断代码的可维护性，挺难的。不过我们可以从侧面，给出一个比较主观又比较准确的判断：如果bug容易修复，修改添加功能能够轻松的完成，那么就可以认为代码比较容易维护，否则就可以说代码不易维护。

可读性

软件设计大师Martin Fowler曾经说过：”Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”，翻译成中文就是傻瓜可以都可以编写计算机能够理解的代码，好的程序员能够编写人能够理解的代码。代码的可读性应该是评价代码质量最最重要的指标之一，毕竟代码被阅读的次数要远远高于代码编写的次数，一个可读性好的代码，往往可维护性也会比较好。
我们需要查看代码是否符合编码规范、命名是否达意、注释是否详细、函数长短是否合适、模块划分是否清晰、是否符合高内聚低耦合等等。
Code review是一个很好的测验代码可读性的手段。如果你的同事可以轻松的读懂你写的代码，那说明你的代码的可读性很好；如果同事在读你的代码的时候，有很多疑问，说明代码可读性有待提高。

可扩展性

可扩展性也是评价代码好坏的一个非常重要的标准。它反映了我们的代码应对未来需求变化的能力。同可读性一样，可扩展性也一定程度上决定了代码的可维护性。
代码的可扩展性表示，我们在不修改或少量修改代码的情况下，通过扩展的方式添加新的功能代码。也就是代码预留了一些功能扩展点，可以把新功能直接插到扩展点上，而不需要因为添加一个新的功能而大动干戈，改动大量的原有的代码。

简洁性

有一条非常著名的设计原则，那就是KISS原则：”Keep It Simple, Stupid”。这个原则说的是尽量保持代码简单。代码简单逻辑清晰，也就意味着易读、易维护。
我们在编写代码时，需要把简单、清晰放到首位。不过很多经验不足的程序员会觉得、简单的代码没有技术含量，喜欢在项目中引入一些复杂的设计模式，觉得这样才能体现自己的水平。实际上，师从深而行从简，真正的高手能云淡轻风地用最简单的方法解决最复杂的问题。我们需要把问题简单化，而不是复杂化。

可复用性

代码的可复用性可以简单的理解为，尽量复用已有的代码，减少重复代码的编写。很多工程师喜欢copy paste代码，这是非常不好的习惯，而是应该抽象从重复的代码。

可测试性

可测试性也是代码质量评判的非常重要的标准。代码可测试性的好坏，可以从侧面反映出代码的质量。代码的可测试性差，很难编写单元测试代码，说明代码写的不够简洁、清晰，设计上有问题。