好代码，满足两个条件：能实现预定效果、能被人容易看懂。
代码的差别，不在于能否实现功能，更主要是实现的好坏。
有些代码虽然实现效果了，但换个程序员就看不懂，无法维护，也是烂代码。
现在的软件业，程序员加班都是普遍现象，疲劳工作，势必影响代码质量。
大部分都在着急实现功能需求，完成领导安排的任务，只是以完成为目标。
这种不考虑长远的工作方式，虽然短时间内达到了目的，但长期看问题很大。
程序员一旦离职，新来的需要花很久才能接手，项目的扩展性和稳定性都没保证。
尤其一些外行的领导，一味地只知道做出来给上级邀功，不能科学的排期。
功能需求说改就改，新功能拍脑袋就来，导致项目设计不断调整，损伤整体的架构稳定。
整个行业还没意识到代码质量的重要性，对代码没有敬畏之心，只看眼前不顾长远。
只有行业人员达到饱和，把不合格的程序员和产品经理都淘汰下去，好代码才能形成风气。
编程界有句名言：“计算机程序是写给人看的，只是顺带计算机可以执行”。
程序易读，没有花架子、没有不必要的提前优化，这是通用的原则。
但是在工程实践上，什么是好的代码，取决于代码满足要的需求的领域。
上图是一段摘自我个人项目的 C 语言代码（业余时间写作，非公司资产），可以看到用到了各种教科书都极力反对的 goto 语句，但实际上，如果是 C 语言比较熟练的话，使用 goto 语句可以大大简化函数返回时的清理代码，达到类似 C++ 语言 RAII 的效果。
再举个例子来说，当你的工作是实现一个被广泛调用的库函数，比如 C 语言 malloc 这样的内存分配函数，那么，速度和内存使用效率就是就是最大的需求，函数实现可以使用各种丑陋的优化技巧甚至内嵌汇编等等，但只要满足基本需求，这些破坏基本可读性原则的手段就不会影响你的代码成为一段好的代码。
在满足需求的前提下，我认为好的代码还符合以下特征：简单性：能用简单实现的方法就不要用复杂的方法，越简单的代码越容易维护；可读性：无论是作者还是他人，都能很容易通过阅读代码了解到代码实现的功能，且代码的编写没有违反常理的地方；分层与模块化：从架构的层面让代码易于理解与修改；优雅与简洁：代码在满足功能需求的情况下尽量采用成熟的算法与逻辑，举个例子，计算从 1 加到 100 的总和，优雅简洁的方法是使用等差数列公式求和而不是用循环累加；效率：一般来说符合上面4条的代码效率不会差，但也应把效率问题牢记在心，比如写 Java 程序，如果遇到多次字符串相加的情况，随时记得用 StringBuilder 来替换简单的字符串连接。
以上是个人对好的代码的几点经验，希望对大家有用。
