给我十天时间，helloworld能给你写出花出来，你信不信？
什么？这个需求明天上线，好吧，先别加注释了，赶紧12点之前调通，别fatory了，先ifelse写死吧！
什么，需求变了要加个分支？来不及，来不及。
不行，领导定了明天必须上，先做个临时版本吧。
……
……
我要花个版本改一下底层结构，要不新需求不能支持。
不行，这个二期需求已经定下来了，开发就给你一周。
*……
代码最基本的要求是要逻辑正确，无论是HappyPath还是有完善的容错机制！
不过代码的好坏不仅仅和编码人员的技术水平相关，还受到其它很多因素的影响：
项目的紧急程度
需求变动程度
人员结构
项目目标
系统架构
......
我们来假设一个场景，题主突然有了一个好点子，希望能做一个基于大数据的系统，协助医生和病人能根据病症给出一些建议。
但是，你现在只有想法，不确定这个系统是否可行，所以你希望能尽快的做出一个MVP，去验证你的想法是否可行。由于现在只有你一个人开发，所以代码写得比较随意，以完成HappyPath为主，尽快的推出一个版本。此时的代码，只要能快速的完成HappyPath就是好代码。
很快，你完成了MVP，验证后发现很受欢迎，于是你就开始后在MVP的基础上进行功能迭代和基本的容错处理。目前还是你一个人在开发，所以此时的代码，能快速完成功能迭代和基本容错处理，就是好代码。
很快，你的系统的用户越来越多，提的意见也越来越多，由于代码过于混乱，改了一个bug，又新增了两个bug！所以，你决定对系统进行重构，使频繁变化的代码独立开，形成独立的模块。此时不引入新bug的代码，就是好代码。
接着，有用户愿意付费了，你一狠心辞职创业了，专心做这个系统。此时系统的稳定新需求越来越高，对系统模块化的需求也越来越高，所以你对系统进行了完整的模块化处理，避免一个模块的逻辑修改，影响了另一个模块。此时一个模块化的代码，就是好代码。
你的业务越来越好，也有了不错的收入，于是你决定招人来一起开发。但是，由于是初创公司，人员流动比较频繁，每个人刚接手项目都要很长时间才能熟悉，且每个人写代码的习惯不同，几轮下来，你就发现代码完全就变味了。所以，你制定了大致的规范，类名怎么取、方法名怎么取，怎么格式化。此时，一个能快速让开发人员上手的代码，就是好代码。
你的系统越来越大，招的人越来越多，现在已经没有人能完整的搞定整个系统了。系统被分成了几个模块甚至子系统，由不同的人负责。此时，保证各个模块/子系统之间不会有影响的代码就是好代码。
最后，好代码不是写出来的，是改出来的！
对于程序员写代码来说，如果仅仅是实现了某个具体功能，那只是一个最基本的要求。
所谓的好代码应该有下面几个特征：
- 首先，程序代码简洁、易懂。即实现同样的功能，代码量不要太多，能抽象精简的尽量抽象精简，尽量封装成子程序或类等，达到代码复用的目的。
- 其次，程序框架要高稳定、易扩展、少耦合。在程序开始设计时，要尽量考虑良性框架的搭建，当后期添加扩展功能时，尽量做到容易添加且不要影响已有功能的实现，所以程序不同模块之间尽量不要有太多的耦合粘连性，而是通过合理的数据接口来实现不同模块间的数据交互。
- 最后，程序代码要有固定的风格，如变量、函数命名规则要符合通用的模式，命名时能够做到望文生义，让别人很容易看懂它代表的含义。
比如下面这两种Python代码，实现同样的功能，很容易看出第2种要比第1种写的要好些。
总之，在平时写代码过程中一定要养成良好的习惯，命名、注释这些千万不要偷懒，时间久了，自然而然就形成了自己的代码风格，可以写出高质量的好代码。
我是雪鹿，是一名科技领域创作者，希望我的回答可以对你有帮助。什么样的代码叫好代码？
我认为要满足三点要求就可以称为好代码。第一是能准确无误的运行并且实现目标功能。第二就是一个实习生程序员都可以看明白的代码。第三就是高效明了。虽然只有这三点，但是我觉感觉要求还是挺高的。
第一是能准确无误的运行并且实现目标功能。一段代码，不能实现某一个模块的功能，或者能实现，但是Bug一堆，问题一片，那可能不叫代码，就是一堆垃圾。更别提是好的代码了。
第二就是一个实习生程序员都可以看明白的代码。实习生程序员都能看懂的代码，也就是新手都能看懂。这不仅要要求代码排版合理，还要有关键的注释，以及很好的命名规范。这一点也是非常重要的，尤其对于软件企业而言，一款软件绝不是一个程序员可以完成的，符合代码规范，才能多人高效的协调合作开发完成软件的开发。如果你写出的软件，别人都看不懂，变量的命名甚至还用a,b,c,或者中文的拼音，那就没啥意思了。
第三就是高效明了。之前我做开发的时候，看过一个工程，功能都挺好的，看了下代码模块，发现了一个重复运行10次的程序块，然后上面就是复制了10遍的代码块。简直爆炸，一个for循环不就可以了吗。所以程序一定不要看起来像一个没技术的写的一样，有时候申明变量没有必要就不用申明，直接用现成的，算法结构能很优化，这样才符合我对好代码的要求。
最后总结:每个程序员都有自己的代码风格，但是能保证简单易读，是基本要求，写代码时加上注释，日后好维护，与人方便与己方便。最后说一句，PHP是这个世界上最好的语言（评论区决战到天亮）
本人是软件行业从业者，也经常考虑这个问题，正好借这个机会说一下个人的一些想法。个人认为好代码，可能需要满足一下一些条件：
第一，实现功能，我认为这也是最重要的。如果你写的代码连最基本的功能都没实现，即使再漂亮再优雅，但一点实用性都没有，这点不满足的话，根本谈不上好代码。所以，我认为最大的质量就是实现功能，没有实现功能，其他的都是白扯。
第二，排版合理。必要的缩进、换行、空行、空格和括号的对齐要合理，代码有层次感。
第三、必要的注释。类注释，说明类的用途，类的作者，可能还有类的用法等说明。方法注释，方法用途，方法作者，继承说明，参数说明，返回值说明等等。变量注释，主要说明变量的用途。代码块的注释，简明扼要的说明代码的作用，让其他人清楚明白。
第四、合理的命名规则。类的命名、方法的命名、变量的命名要有意义，易懂。
第五、编码中需要注意的一些事项和遵循的原则。比如输入流和输出流的关闭，需要在finally中进行操作。比如在代码中注意判空，防止NPE的出现。比如对大文件的处理，不要一下子读入内存，防止内存爆掉。比如注意抽取常量，统一处理，便于维护。比如对异常，最好进行精细化处理，可针对不同进行不同操作等等。还有一些基本原则，比如单一原则，方法实现功能尽量单一。比如开闭原则，比如依赖倒置原则，比如接口隔离原则，比如DRY原则等等。
第六、设计模式的使用。合理的使用设计模式，可以减少你代码的耦合度，提高代码的扩展性，提高可维护性。另外，可借助框架来减少你代码的耦合度，比如我们经常提到的spring。
第七、合理的设计。进行必要的设计，但不会过度设计，让代码满足当前的需求。好的架构一般是演化出来的，未必是一次设计出来的。
本人具有多年的java开发经验，熟悉多种框架，熟悉网络编程，熟悉java安全编程，熟悉大数据，熟悉多种安全协议，熟悉并发编程，有兴趣的同学可以互相关注，互相学习！！！
在我看来，好的代码分成这几个层次：
实现功能（需求）单纯的把需求实现，只能算“合格”的代码，如果要成为（初级）好代码，我认为还需要做到下面几点：
代码的健壮性：需要多考虑规范要求以外的可能，我经常对组员说“不要相信别人，我们要把自己的代码考虑全面”；比如开发一个接口，双方已经约定某个字段是必传的，那么是相信对方系统会传这个字段，还是“不要相信对方”，接口中增加非空判断。
代码效率：在工作期间，我发现很多开发人员很容易犯的一个错误，就是只关注功能的实现，而不会考虑代码执行效率；例如测试环境数据库中有一万的数据，随便写个SQL也不会发生效率问题，但是生产环境一千万的数据，代码一上生产就会出现问题（项目最好能提供一个准生产环境，或者生产环境的试运行）。
一方面，软件开发需要团队合作，另外一方面，程序员岗位的流动性比较强，可能两三年过后，项目组成员已经完全换了一拨人了；所以代码容易阅读，是很重要的。
遵守代码规范：代码分层、起名见名知意、代码样式等等；
准确的代码注释，接口必须有接口文档；代码修改之后，对应的注释和文档必须也对应修改；
少些代码不代表让你偷懒，要想写出【好代码】，一定不能只【看到代码】。
深入了解需求，不合理的需求或者重复的功能，可以拒绝，或者给出其他的建议；
设计和写代码的时间投入，一定要合理安排，甚至有些时候，设计的时间翻到更长；
能复用的尽量复用，能抽象的尽量抽象，以便以后可以复用；
如果有经过实际考验的【*】，那就直接拿来使用；
时刻要注意“过犹不及”：千万不要学了什么新的技术（框架、设计模式等），一定要用到项目中，而不是考虑是否合理，是否适用。
谢谢邀请，
代码的本质还要在机器上运行，好的代码不单单的纯粹的简单的几个字符的问题，好的代码不仅仅是排版上或者语法上好看，还要能经过产品的测试验证，这是评判代码好坏的最准确的标准。不同水平的人对代码的理解是不一样的，现在就是三种水平的人分析对待代码的不同态度，代码能够在表面上看到水准，深层次只能靠实践验证。
在初级程序员的眼里代码就是天了，能够用代码实现领导布置的技术任务，就是最大的满足了，几乎所有的精力都在代码上体现出来，拿到需求的第一时间就是会问自己代码如何去写，是不是会写，如果不会写该怎么办，这也是通常刚入门的程序员要克服的事情，这个阶段对于程序员的要求过多也不是很现实，毕竟刚开始还在解决温饱阶段的时候，不能强求吃的非常奢侈，而且这个阶段的程序员能够实现一个基本功能就能获得巨大的成就感，每个阶段追求的层面不一样，代码的严谨程度实现方式等等都是存在巨大的优化空间，甚至还有一些废物代码都是存在的。
中级程序员已经能够对代码有基本的掌控能力了，拿到需求之后已经开始考虑用什么方式实现起来更加稳定可靠，这个阶段的程序员编码水平属于基本功能做的可靠扎实，已经能够驾驭代码了，拿到需求之后不是先问代码如何实现，而是会从试下上看看有没有更好的实现方式，绝大多数程序员属于这个水准，基本上也会分成以下几种情况，看到差不多的功能从网上找对应的代码，看明白之后直接拷贝过来修改成适合当前框架的代码风格，这个时候的程序员普遍上已经对编程有了感觉，觉得编程也就是这么回事，很多程序员这个时候放松了对自己的要求，不像刚入行那种诚惶诚恐的样子了，越是这个阶段越是要保持一种前进的动力。因为很多年龄大的程序员后面跟不上节奏了，就是从这个阶段开始的。
高级软件工程师对于代码的依赖性更少了，考虑不仅仅是实现功能问题了，拓展性兼容性以及跨平台都是在考虑的范畴，甚至还会考虑*的使用是不是靠谱，还有再优秀点就考虑如何造*，即使造不出来也会尝试去积累经验，毕竟不是每个人都能有机会架构一个框架，但起码在平时的工作过程中会一直准备着，所以等到有了机会之后紧紧抓住，现在能成为架构师的人基本上都是这么出来的，说到代码就会涉及到编程语言的范畴，编程语言也好代码也好都是工具般的存在，工具就是为框架服务的，基本上这个层面的程序员是用这种方式对待代码的。
当然基本的代码需要好的规程规范，需要遵循基本的编程语法，起码让人能看懂，如果一个人写的代码只能自己看懂，这属于比较失败的程序员，越是复杂的功能通过代码的实现变得简单化，这才是程序员追求的目标，现在几乎巨头公司都有自己的编码规范，就是制定一个统一的标准方便程序员去编程，对于代码来讲一年不懂可以两年甚至三年早晚能够搞明白。编程思想的锤炼才是高手的晋级之路。
希望能帮到你。
一段好的代码，最少要遵守基本的编程规范，比如命名方式，注视等等，就拿变量名来说，必须让人通过字面意思大概能知道这个变量是做什么的，代表什么意思，阅读性要好，否则其他人看到代码跟看天书一样，完全不知道是在做什么。同样的，方法命名也是一个道理。
以下图举例来说，两个方法都是检查用户名与密码是否为空，但是第一个方法明显规范于第二个方法，变量名就是账号与密码的英文单词，一看就明白，而第二个方法以a，b，c来命名，没人知道是啥意思，这种代码是最差的。
编程界有句名言：“计算机程序是写给人看的，只是顺带计算机可以执行”。程序易读，没有花架子、没有不必要的提前优化，这是通用的原则。
但是在工程实践上，什么是好的代码，取决于代码满足要的需求的领域。
上图是一段摘自我个人项目的 C 语言代码（业余时间写作，非公司资产），可以看到用到了各种教科书都极力反对的 goto 语句，但实际上，如果是 C 语言比较熟练的话，使用 goto 语句可以大大简化函数返回时的清理代码，达到类似 C++ 语言 RAII 的效果。
再举个例子来说，当你的工作是实现一个被广泛调用的库函数，比如 C 语言 malloc 这样的内存分配函数，那么，速度和内存使用效率就是就是最大的需求，函数实现可以使用各种丑陋的优化技巧甚至内嵌汇编等等，但只要满足基本需求，这些破坏基本可读性原则的手段就不会影响你的代码成为一段好的代码。
在满足需求的前提下，我认为好的代码还符合以下特征：
简单性：能用简单实现的方法就不要用复杂的方法，越简单的代码越容易维护；
可读性：无论是作者还是他人，都能很容易通过阅读代码了解到代码实现的功能，且代码的编写没有违反常理的地方；
分层与模块化：从架构的层面让代码易于理解与修改；
优雅与简洁：代码在满足功能需求的情况下尽量采用成熟的算法与逻辑，举个例子，计算从 1 加到 100 的总和，优雅简洁的方法是使用等差数列公式求和而不是用循环累加；
效率：一般来说符合上面4条的代码效率不会差，但也应把效率问题牢记在心，比如写 Java 程序，如果遇到多次字符串相加的情况，随时记得用 StringBuilder 来替换简单的字符串连接。
以上是个人对好的代码的几点经验，希望对大家有用。
好代码，满足两个条件：能实现预定效果、能被人容易看懂。
代码的差别，不在于能否实现功能，更主要是实现的好坏。
有些代码虽然实现效果了，但换个程序员就看不懂，无法维护，也是烂代码。
现在的软件业，程序员加班都是普遍现象，疲劳工作，势必影响代码质量。
大部分都在着急实现功能需求，完成领导安排的任务，只是以完成为目标。
这种不考虑长远的工作方式，虽然短时间内达到了目的，但长期看问题很大。
程序员一旦离职，新来的需要花很久才能接手，项目的扩展性和稳定性都没保证。
尤其一些外行的领导，一味地只知道做出来给上级邀功，不能科学的排期。
功能需求说改就改，新功能拍脑袋就来，导致项目设计不断调整，损伤整体的架构稳定。
整个行业还没意识到代码质量的重要性，对代码没有敬畏之心，只看眼前不顾长远。
只有行业人员达到饱和，把不合格的程序员和产品经理都淘汰下去，好代码才能形成风气。