衡量代码的好坏的指标或者维度有很多，比如性能好、架构好、高内聚等，这些指标的侧重点各不相同，不同的开发人员的关注的重点也各不相同。我个人更喜欢简单的可读性高的代码，我主要从以下几个维度衡量代码是否良好：
- 代码是可工作的
- 代码是可读性高的
- 代码是简单的
- 代码是高内聚的
- 代码是低耦合的
代码是可工作的
写代码的目的是要为了解决特定问题的，因此无论如何，代码首先是可工作的，能解决特定的问题。可工作的包含有两层含义：一是从功能角度来说能满足用户的需求，二是从性能角度来说要满足当前基本的性能需求。所以可工作是衡量代码好坏的前置条件，只考虑代码本身不考虑可工作性是舍本取末。
代码是可读性高的
代码是开发人员来开发和维护的，而且在软件漫长的生命周期中，通常会由不同的开发人员来维护的，如果代码的可读性很差，那将来的维护就将是一个噩梦。我们写的代码是给开发人员看的，绝对不是给机器看的（编译后的代码是给机器看的，编译器会帮我们去掉无意义的空行等），因此代码必须首先是可读性高的。
那什么是可读性高的代码呢？从 coding style 角度来说，有意义的命名、添加必要的文档和注释、类和方法不要太长、每一行也不要太长、添加必要的空行以及必要的缩进等，具体可以参考《C++编程规范》和《重构改善既有代码的设计》。另外一方面就是从代码的结构来定义，例如代码是高内聚、低耦合的，代码是简单的，这三个方面下面会有详细描述。
代码是简单的
我们先来看一下什么是复杂的代码，比如说美其名曰为了代码的扩展性，使用了好多设计模式和软件开发原则，结果就是明明可以用很简单几行代码搞定的事情，结果用了几十行代码甚至更多，而且代码用了各种酷炫的技术，但是事实上大部分的扩展性可能一辈子也没有发生过，从敏捷开发角度来说，这是非常典型的过度设计。敏捷开发不是不考虑设计，只是不推崇过度设计，比如考虑 10 年后系统的扩展性是没有任何意义的，另外一种场景是只是做一个简单的后台管理系统，但是却花大量的精力考虑高并发也是没有意义的，过度设计的代码通常是复杂的。
所以在适度考虑代码的可扩展性的基础上，能不用设计模式就不要用设计模式，能不用新的、复杂的技术就不用新的、复杂的技术，技术够用就好，代码越简单越好，有人说代码太简单是不是有点 low，其实写出高质量的简单代码远比写出复杂的代码难度高，尤其是系统比较复杂时，保持代码的简单性难度是非常大的。
所以说简单的代码就是：代码所有人都看得懂，尤其是新人，但是又具备一定的扩展性和维护性，简单的讲就是简约而不简单。复杂的代码首先对读代码的人要求就很高，最终导致代码很难维护。代码是简单的是代码可读性高的一个方面。
代码是高内聚的
内聚是从功能角度来度量模块内的联系，代码关联性比较强的代码应该放在内聚在一起，形成一个独立的功能模块，可以是一个独立的类，也可以是一个微服务。其实判断代码是否内聚一个比较简单的方法就是看你能否给代码或者服务给一个贴切的名字，如果代码功能不内聚，我们是很难用一个简短的名字来表示它的含义的。
代码是低耦合的
耦合性(Coupling)，也叫耦合度，是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。
耦合比较高的代码危害比较大，最常见的表现就是改一个模块的代码会影响许多其它模块，最终必然导致大家不敢修改旧的代码，只能不停的添加新的接口，系统的可维护性非常差。