thfghfg
好代码，满足两个条件：能实现预定效果、能被人容易看懂。
代码的差别，不在于能否实现功能，更主要是实现的好坏。
有些代码虽然实现效果了，但换个程序员就看不懂，无法维护，也是烂代码。
现在的软件业，程序员加班都是普遍现象，疲劳工作，势必影响代码质量。
大部分都在着急实现功能需求，完成领导安排的任务，只是以完成为目标。
这种不考虑长远的工作方式，虽然短时间内达到了目的，但长期看问题很大。
程序员一旦离职，新来的需要花很久才能接手，项目的扩展性和稳定性都没保证。
尤其一些外行的领导，一味地只知道做出来给上级邀功，不能科学的排期。
功能需求说改就改，新功能拍脑袋就来，导致项目设计不断调整，损伤整体的架构稳定。
整个行业还没意识到代码质量的重要性，对代码没有敬畏之心，只看眼前不顾长远。
只有行业人员达到饱和，把不合格的程序员和产品经理都淘汰下去，好代码才能形成风气。
台哥彩铃
编程界有句名言：“计算机程序是写给人看的，只是顺带计算机可以执行”。程序易读，没有花架子、没有不必要的提前优化，这是通用的原则。
但是在工程实践上，什么是好的代码，取决于代码满足要的需求的领域。
上图是一段摘自我个人项目的 C 语言代码（业余时间写作，非公司资产），可以看到用到了各种教科书都极力反对的 goto 语句，但实际上，如果是 C 语言比较熟练的话，使用 goto 语句可以大大简化函数返回时的清理代码，达到类似 C++ 语言 RAII 的效果。
再举个例子来说，当你的工作是实现一个被广泛调用的库函数，比如 C 语言 malloc 这样的内存分配函数，那么，速度和内存使用效率就是就是最大的需求，函数实现可以使用各种丑陋的优化技巧甚至内嵌汇编等等，但只要满足基本需求，这些破坏基本可读性原则的手段就不会影响你的代码成为一段好的代码。
在满足需求的前提下，我认为好的代码还符合以下特征：
简单性：能用简单实现的方法就不要用复杂的方法，越简单的代码越容易维护；
可读性：无论是作者还是他人，都能很容易通过阅读代码了解到代码实现的功能，且代码的编写没有违反常理的地方；
分层与模块化：从架构的层面让代码易于理解与修改；
优雅与简洁：代码在满足功能需求的情况下尽量采用成熟的算法与逻辑，举个例子，计算从 1 加到 100 的总和，优雅简洁的方法是使用等差数列公式求和而不是用循环累加；
效率：一般来说符合上面4条的代码效率不会差，但也应把效率问题牢记在心，比如写 Java 程序，如果遇到多次字符串相加的情况，随时记得用 StringBuilder 来替换简单的字符串连接。
以上是个人对好的代码的几点经验，希望对大家有用。
命叔炸机
一段好的代码，最少要遵守基本的编程规范，比如命名方式，注视等等，就拿变量名来说，必须让人通过字面意思大概能知道这个变量是做什么的，代表什么意思，阅读性要好，否则其他人看到代码跟看天书一样，完全不知道是在做什么。同样的，方法命名也是一个道理。
以下图举例来说，两个方法都是检查用户名与密码是否为空，但是第一个方法明显规范于第二个方法，变量名就是账号与密码的英文单词，一看就明白，而第二个方法以a，b，c来命名，没人知道是啥意思，这种代码是最差的。
allen5168
本人是软件行业从业者，也经常考虑这个问题，正好借这个机会说一下个人的一些想法。个人认为好代码，可能需要满足一下一些条件：
第一，实现功能，我认为这也是最重要的。如果你写的代码连最基本的功能都没实现，即使再漂亮再优雅，但一点实用性都没有，这点不满足的话，根本谈不上好代码。所以，我认为最大的质量就是实现功能，没有实现功能，其他的都是白扯。
第二，排版合理。必要的缩进、换行、空行、空格和括号的对齐要合理，代码有层次感。
第三、必要的注释。类注释，说明类的用途，类的作者，可能还有类的用法等说明。方法注释，方法用途，方法作者，继承说明，参数说明，返回值说明等等。变量注释，主要说明变量的用途。代码块的注释，简明扼要的说明代码的作用，让其他人清楚明白。
第四、合理的命名规则。类的命名、方法的命名、变量的命名要有意义，易懂。
第五、编码中需要注意的一些事项和遵循的原则。比如输入流和输出流的关闭，需要在finally中进行操作。比如在代码中注意判空，防止NPE的出现。比如对大文件的处理，不要一下子读入内存，防止内存爆掉。比如注意抽取常量，统一处理，便于维护。比如对异常，最好进行精细化处理，可针对不同进行不同操作等等。还有一些基本原则，比如单一原则，方法实现功能尽量单一。比如开闭原则，比如依赖倒置原则，比如接口隔离原则，比如DRY原则等等。
第六、设计模式的使用。合理的使用设计模式，可以减少你代码的耦合度，提高代码的扩展性，提高可维护性。另外，可借助框架来减少你代码的耦合度，比如我们经常提到的spring。
第七、合理的设计。进行必要的设计，但不会过度设计，让代码满足当前的需求。好的架构一般是演化出来的，未必是一次设计出来的。
本人具有多年的java开发经验，熟悉多种框架，熟悉网络编程，熟悉java安全编程，熟悉大数据，熟悉多种安全协议，熟悉并发编程，有兴趣的同学可以互相关注，互相学习！！！
代码饲养员天齐
关于什么是好代码，软件行业烂大街的名词一大堆，什么高内聚、低耦合、可复用、可扩展、健壮性等等。
一、也就是所谓设计6原则 — 迪米特法则（最少知道原则） 加上 SOLID :
1、Single Responsibility （单一职责）
2、Open Close（开闭）
3、Liskov Substitution（里氏替换）
4、Interface Segregation（接口隔离）
5、Dependency Inversion（依赖反转）
二、函数不易太长
如果太长（一般不宜超过200行,但不绝对），你自己都不太容易读懂，请不要犹豫，分解成模块函数吧。
假设你的项目中有三个不同的层——内层、中层和外层。你的内容不应该从中层和外层那里导入任何东西。中层不应该从外层导入任何东西 ，这样做的好处是，你可以对代码的内层进行独立测试
三、变量名、函数名称、类名、接口等命名含义不清晰
函数名能让人望名知义，看名字就知道函数的功能是啥，以至于几乎不需要多少comments最好
四、学习习惯
1，先学习业务知识，分析业务，对自己的定位是业务领域专家，能快速通晓这个领域大部分的业务知识。
2，业务建模，抽象，能反映这个业务领域的各种变化。
3，只使用JDK进行编程，概念和抽象意义上的编程（算是：瘦核心/领域驱动/微内核模式的开发习惯）。
4，使用JDBC,JMS。。。。等框架，将概念具体功能和扩展落地
大黄哥儿
在我看来，好的代码分成这几个层次：
实现功能（需求）
单纯的把需求实现，只能算“合格”的代码，如果要成为（初级）好代码，我认为还需要做到下面几点：
代码的健壮性：需要多考虑规范要求以外的可能，我经常对组员说“不要相信别人，我们要把自己的代码考虑全面”；比如开发一个接口，双方已经约定某个字段是必传的，那么是相信对方系统会传这个字段，还是“不要相信对方”，接口中增加非空判断。
代码效率：在工作期间，我发现很多开发人员很容易犯的一个错误，就是只关注功能的实现，而不会考虑代码执行效率；例如测试环境数据库中有一万的数据，随便写个SQL也不会发生效率问题，但是生产环境一千万的数据，代码一上生产就会出现问题（项目最好能提供一个准生产环境，或者生产环境的试运行）。
让别人能看懂
一方面，软件开发需要团队合作，另外一方面，程序员岗位的流动性比较强，可能两三年过后，项目组成员已经完全换了一拨人了；所以代码容易阅读，是很重要的。
遵守代码规范：代码分层、起名见名知意、代码样式等等；
准确的代码注释，接口必须有接口文档；代码修改之后，对应的注释和文档必须也对应修改；
少些代码
少些代码不代表让你偷懒，要想写出【好代码】，一定不能只【看到代码】。
深入了解需求，不合理的需求或者重复的功能，可以拒绝，或者给出其他的建议；
设计和写代码的时间投入，一定要合理安排，甚至有些时候，设计的时间翻到更长；
能复用的尽量复用，能抽象的尽量抽象，以便以后可以复用；
如果有经过实际考验的【轮子】，那就直接拿来使用；
时刻要注意“过犹不及”：千万不要学了什么新的技术（框架、设计模式等），一定要用到项目中，而不是考虑是否合理，是否适用。
希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
我是雪鹿，是一名科技领域创作者，希望我的回答可以对你有帮助。
什么样的代码叫好代码？
我认为要满足三点要求就可以称为好代码。第一是能准确无误的运行并且实现目标功能。第二就是一个实习生程序员都可以看明白的代码。第三就是高效明了。虽然只有这三点，但是我觉感觉要求还是挺高的。
第一是能准确无误的运行并且实现目标功能。
一段代码，不能实现某一个模块的功能，或者能实现，但是Bug一堆，问题一片，那可能不叫代码，就是一堆垃圾。更别提是好的代码了。
第二就是一个实习生程序员都可以看明白的代码。
实习生程序员都能看懂的代码，也就是新手都能看懂。这不仅要要求代码排版合理，还要有关键的注释，以及很好的命名规范。这一点也是非常重要的，尤其对于软件企业而言，一款软件绝不是一个程序员可以完成的，符合代码规范，才能多人高效的协调合作开发完成软件的开发。如果你写出的软件，别人都看不懂，变量的命名甚至还用a,b,c,或者中文的拼音，那就没啥意思了。
第三就是高效明了。
之前我做开发的时候，看过一个工程，功能都挺好的，看了下代码模块，发现了一个重复运行10次的程序块，然后上面就是复制了10遍的代码块。简直爆炸，一个for循环不就可以了吗。所以程序一定不要看起来像一个没技术的写的一样，有时候申明变量没有必要就不用申明，直接用现成的，算法结构能很优化，这样才符合我对好代码的要求。
最后总结:每个程序员都有自己的代码风格，但是能保证简单易读，是基本要求，写代码时加上注释，日后好维护，与人方便与己方便。
最后说一句，PHP是这个世界上最好的语言（评论区决战到天亮）
以上是我对这个问题的解答和观点，纯手打，实属不易，也仅表达个人观点，希望能给读者很好的参考，若是觉得写的还可以就给个赞吧。
雪鹿生活科技
正好，我本身就是一名程序员，在这行里做了五年了，所以来回答下这个问题。
其实，代码的价值并不在于代码本身，而是在于代码构建出来的产品的价值。一款产品从无到有再到好，离不开代码的一步步累积！因此，代码是动态的，是不断更新迭代的。在这个过程中，面向开发人员的代码，自然就会被开发人员评判为好代码和坏代码之分。
首先，我认为好的代码要让人能看得懂它的逻辑和表达意思！代码是人写的，也是需要人来不断维护的，谁都无法保证开发人员就是维护人员，因此，一款产品的代码，如果每个来接手的人都根本看不明白前面的人写的是什么意思，自然而然会影响到产品的更新迭代，甚至会在迭代过程中出现致命的问题。
其次，好的代码不但要让人看的懂，还要让人看的舒服。因此，这就需要技术人员在写代码过程中要遵守编程规范，或者是这一套代码里体现出来的自己的规范。要保持整套代码的规范和习惯的一致性。比如：这套代码里变量名的命名方式是驼峰法，你就用驼峰法，如果是下划线全小写法，你也就用下划线全小写法。
第三，好的代码要简洁明了。具有共性的功能模块最好进行封装，不要哪个地方用到，就把所有的逻辑都再写一遍。同时，要注意MVC架构，处理接受和逻辑尽量放在C层，处理数据的尽量放在M层。
第四，好的代码要足够健壮。足够健壮包含了两个层面，一个就是上面所提到的尽量简洁化代码，要有封装；还有就是要多考虑情况的场景的复杂性，在代码中提早最好控制，尤其是针对客户端输入的情况，不要相信客户端的输入是安全的。
最后，好的代码，最好是在合适的地方加上合理的注释，帮助自己和别人快速理解，切不可以为自己写的就永远记得，没有哪个程序员能永远记得自己写的代码是什么意思，更不要说别人了！
浅谈不深究
好代码这个概念太宽泛了。抛开需求以及架构等我觉得好代码应该符号这几个标准。
第一， 符号开发规范。别的开发语言不清楚，Java我还是有发言权的。比如大名鼎鼎的驼峰命名，代码缩径，以及每行字符长度等。符号规范的代码更易阅读，这样哪天你换别的项目或跳槽交接起来也方便点。
第二，加合理的注释。我一直认为注释是属于代码的重要组成。没有注释的代码是很难理解的。尤其是业务复杂的项目，当初你耗费几周写出的代码，如果没注释，过一段时间再看也一样会懵逼。
第三，选用合理的数据结构。对于数据结构没有绝对的好与坏，只不过是使用场景不同罢了。当然最常用的数据结构也不过是List和Map。
第四，简单易懂，一份好的代码应该简单易懂，而不是为了为了语法而写。比如你虽然清楚记得运算符的优先级，但是为了可读性还是要人为加括号。
以上就是我所认为的好的代码。
但求无Bug
第一，具备可读性，这就意味着全公司应该有统一的编码规范和风格，例如：统一的命名规范、统一的注释要求……
第二，没有明显漏洞，不存在安全隐患，业界也有很多漏洞检查工具，例如：C++领域的coverity……可以快速识别代码风险和漏洞
第三，可复用和可被复用，包括复用了已有的代码，以及新写的代码未来也可被复用
