风乱语
0x01 先看注释
这一点很重要，放在第一点来说。很大程度上注释反映了一个程序员的编码思路，你可以从注释中看到一个程序员对业务的理解程度，甚至编码的态度。好的注释可以让你轻松的阅读代码，不费吹灰之力快速了解一段代码的核心思路，仿佛一切都是水到渠成，对这种代码的修改或者扩展也是如沐春风。但是如果一段代码注释混乱或者根本就没有注释，那么后期维护难度可想而知，即使原作者过个把月再回来看这段代码也会骂一句，屎一样。
0x02 代码整齐度
这个很好理解，举个栗子，见下图
这种代码让人提不起阅读的欲望，写这种代码的程序员是不是一个好的程序员大家自己判断。
再看看下面这段
欢迎大家关注 嵌入式疯狗 狗哥等你来一起玩耍哈
嵌入式疯狗
写了十多年代码，见过很多烂代码，也见过不少优秀的代码，那么如何判断代码的好与坏呢，我谈谈自己的看法。
好的代码，就算外行看到也会说是好代码
首先，好的代码会严格遵守代码规范。从代码的格式、命名、注释，就能看出来代码的好坏：遵守代码规范的代码不一定好代码，但好代码一定会遵守代码规范。
所以我经常说，好的代码，让一个外行人看，就算他看不懂写的什么，但是他也会说写的不错。
实现需求，并考虑可扩展性
代码必须要实现需求，这是及格线，对于好的代码，评定标准会更高。
举个简单的例子：
客户提了一个需求，查询展示客户列表，对于账户余额超过10万的客户，标红展示。
代码也很容易，余额>=10万{特殊处理}。
过几天，需求说，10万这个标准有些低了，变成50万吧。
然后改代码，余额>=10万{特殊处理}，然后上线。
又过了几天，需求说，50万有些高了，调整成30万吧...
如果把这个限额标准做成可配置的，是不是就灵活很多。（你要是把配置放在数据库中，每次判断去查询的话，你还是写死在程序里面吧）
我们圈子里就有一个传言：一个优秀程序员的品质，就是可以准确的蒙对客户要变化的需求。
注重业务功能，也要注重代码效率
工作十多年，我遇到很多这样的程序员：一心一意实现业务逻辑，在测试环境跑的没有问题，一上生产就卡死。因为测试环境有一千条数据，生产环境有一千万条数据。
所以好的代码，会根据实际生产环境的实际情况，进行一定程度的设计和优化。（优化是无止境的，适度就好）
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
理论上讲，好的代码要简洁，逻辑清晰，易扩展，良好的封装等等。
但在实际中，吐槽代码已成了程序员的日常。
借用亚马逊工程师的话，来形容说他们的代码:“一座很大的屎山，你见过的最大的山，每次你想修正一个bug，你的工作就是爬到屎山的正中心去”。
我们组曾有一个著名的6000行后端JS，没有面向对象封装，纯靠函数。 其中有好几个上千行的函数，带了二十多个形参，几个标志位，分别有十几个数字状态。注释？没有的。
每一个接手过这段代码的人都会不约而同的发一条朋友圈以示佩服。
但神奇的是，代码在执行上基本没太多的错。
直到几个月前，一个大牛在走之前把这段代码全部重写了一遍，留下了至今都没有改完的bug。
非著名程序猿
Java程序员中非常流行阿里巴巴Java编码规范，这是阿里对Java程序员的规范要求，一公布引起很大反响，笔者作为把阿里规范看了不下五遍的人，不得不承认如果代码能按照编码规范来写，那将是非常优秀的。不仅仅是影响了代码的整洁度，有些规范的编写将非常有利于软件的性能和稳定性。
判断代码好坏我有以下几个方法:
- 首先先看代码的规范性，比如驼峰写法，比如是否在每个接口处都带有注释。这些可以用阿里插件扫描。
- 其次，可以用sonar等工具进行扫描，看看代码是否有空指针的可能性，还有些“坏味道”的代码。
- 最后，可以看看这些代码的细节，具体实现方式，在核心算法里有没有注释，是否冗余，是否会有更好的写法替代。
关注“极客宇文氏”更多干货经验分享。极客宇文氏
作为一名从事互联网行业多年的老程序员，我来回答一下这个问题。
在我看来程序员代码的好坏标准也与计算机行业的发展有密切的关系，早期的程序员非常注重代码的执行效率，比如时间复杂度和空间复杂度等，当前的程序员对代码的可读性和规范性也非常重视，因为目前的软件开发都是团队行为，团队合作一定要有规范性的代码要求。
我目前对团队程序员的代码要求主要集中在以下几点：
第一，代码的规范性。所谓代码的规范性指的就是代码的模块清晰、可读性强、格式良好、命名合理、注解详细。代码的好坏第一眼是模块划分是否清晰，然后是格式，再然后是逻辑是否清晰。如果这段代码执行的结果是正确的，但是逻辑混乱，这样的代码就不是好的代码，这也是很多初级程序员经常犯的错误，如果不及时指正，对他未来的发展会非常不利。
第二，代码的执行效率。代码的执行效率往往体现了一名程序员的能力，不同的代码在执行效率上差距非常大。代码的执行效率涉及到时间复杂度、空间复杂度，对算法的选择和实现思路决定了程序的执行效率。有经验的老程序员往往在执行效率上有多套完整的解决方案，这是年轻程序员需要重点学习和提高的地方。
第三，代码的扩展性。代码的扩展性主要体现在代码结构的设计上，运用规范的模式能够在很大程度上保证代码的扩展性。程序没有不修改的，修改就涉及到功能的扩展，而好的代码在功能扩展上就比较方便。比如在完成一个简单的数据存取功能的时候，程序员会按照实体类、接口、实现类、工厂类的结构来设计，这样以后的扩展会非常简单。
最后，不同的开发团队往往有不同的规范要求，程序员一定要仔细学习并掌握，这对以后的团队合作非常重要。作为软件团队的一份子，一定要记住不要犯低级错误！
我带软件团队多年，我会陆续在头条上分享一些开发方面的科普文章，感兴趣的朋友可以关注我的头条号，相信一定会有所收获。
如果有开发方面的问题，或者是考研方面的问题，都可以咨询我。
谢谢！
IT人刘俊明
我想把这个问题转化为两个部分：第一个部分是怎么判断程序员的代码好不好，第二部分想说说什么样的程序员，才是好的程序员。
好的代码，就像是小说家手中的短篇小说，逻辑清晰，简单明了，却又能触动心灵，而坏代码，就像是一辆外表富丽的老旧汽车，开不动不说，随时还有散架的危险。
究竟什么样的代码才能算是好代码？这是一个很有争议的话题，每个人的理解可能都不一样，所以制定一个符合自己部门要求的规范，有了依据，写出来的代码才有可能成为好代码。
思考了一下题主提问题的场景，应该有两种情况。一种是，就是自己本身不懂代码，只是想知道怎么判断一个程序员的代码质量另外一种情况，自己本身就是程序员，可能是刚学不久，不知道怎么判断好代码的标准。
不懂代码，如何判断
如果你不懂代码，那就直接判断这个程序员是不是好程序员吧，判断代码，也不是你可以做的事。下面我会提到这一点。
好代码的判断标准
可读性
好的代码本身就是最好的说明文档——Steve McConnell
代码几千行，所有业务逻辑全部揉在一起，除了你没人看得懂，周末想续写代码，结果发现连自己也要看半天，才能接着写下去，这样的代码，能是一个好代码吗？
判断：将代码拿给其他程序员看，在读代码期间，他向你提出的问题越少，说明这些代码的可读性也就越强。
要想让部门所有人写出的代码可读性强，就必须制定一个统一的开发风格，这样不管是老程序员还是新程序员，都能快速上手，可读性也会得到一定的保障。
可维护性
曾经看过一段代码，一个method几千行代码，没有人敢维护，修改一点点就会发生不可知的错误，代码又臭又长，除了重构，完全没有办法。这样的代码，就是一个差到不行的代码。
判断：一般有三点可以做个大概的判断，一是易读，二是可拓展，三是数据灵活，四是可追踪。
简洁性
很多程序员之所以喜欢写长代码，主要是写起来没什么障碍，也不用怎么思考，跟记流水账一样。还有就是学习的时候，养成了一些不良的编程习惯，亦或是习惯成自然，已经不知道自己所写的代码，是不是够简洁了。
判断：拿出以前写过的代码，读一下，看看是不是简洁了，如果是，至少说明你现在写的代码，比以前简洁了。
模块化
好的代码，都是模块化的。假设你的项目有三个不同的层，分别为内层、中层和外层。你的内容不应该从中层和外层那里导入任何东西。中层不应该从外层导入任何东西，这样做的好处是，你可以对代码的内层进行独立测试。
好程序员的判断
出货能力
写一个程序，算法非常精妙，代码质量也非常高，但产出效率非常低，也不能算是一个号程序员。之前我看过一个所谓的大神，算法很溜，但做事根本没办法按时完成进度，这也不行。
优化能力
没有一个程序，是一步到位的，很多时候随着业务的增大，对性能的要求越来越高，有一定的代码优化能力也是非常重要的。
调错能力
项目越大，遇到的bug会越力气，这时候就需要强大的debug能力，找出最为关键的错误点，甚至追溯底层框架的源码。
bug是不可避免的，但一个好的程序员，基本上不会因为代码数量的增多，而导致bug也同步增多，如果原本bug是10占1，后来代码增多了，变为100占3，而不是100占10.
技术掌控
你的项目能用spring，hibernate等等框架，但是对于这些技术，你真的掌控了吗？假如有一点，框架版本需要升级，你做得到吗？或者从hibernate转为mybatis？
剩下的，一些非技术相关的能力，比如学习能力、抗压能力，这里就不多说了。
——摘自W3Cschool学员的回答
W3Cschool
好的代码简单明了，逻辑清晰，那么好的代码规范要求如下：
1、代码是否符合业界通用规范，如Java语言的标识符的命名规范
1)、变量、方法：
1)、单个单词：全部小写
2)、多个单词，首单词小写，其后的单词首字母大写，小驼峰标识
2)、类、接口： 所有单词首字母均大写，大驼峰标识
3)、包：小写字母组成,域名反着写
4)、统一的缩进
5)、变量、方法、类命名要见名知意
6)、良好的注释
7)、大小写敏感问题
2、可读性强：代码不是只写给自己看的，几千上万行代码，几个业务逻辑柔和在一起，要想改也不知道头绪，看了半天才能继续往下写，将代码拿给其他程序员看，在读代码期间，他向你提出的问题越少，说明这些代码的可读性也就越强。要想可读性强，必须有良好的统一编码风格！
3、代码是否简介，一个代码能用一行的尽量不用2行
4、代码是否可重用，同一个功能尽量不要在多处重复书写。
5、代码是否安全，代码是否有考虑一些常见的安全问题和边界问题，如SQL注入、XSS攻击、CSRF攻击等等。
6、性能是否好，你写的代码最终是要运行的，如果性能不好，是会影响用户体验的。
ITmian
我来说说我在工作中遇到的一个例子，某天因为业务需要，要修复一个bug，找到bug相关代码，一看代码，差点把我吓死，大家猜猜怎么着？一个定时工作的job类，五百多行代码，只有一个方法，代码中命名混乱，各种不在一个抽象层级的代码混杂在一起，更让人气愤的是全篇没有一行注释！一看到这种代码，就没一点心情看下去了，奈何bug要修复啊，只能硬着头皮看了，最后花了好长时间才找到问题原因，将bug修好，而我已经早已头昏脑胀，不知道问候过多少遍这个奇葩的前辈了。
看完我这个实实在在的例子，要如何判断一个程序员写的代码好不好，其实已经很清楚了！
首先要有完整清晰的代码结构，起码要一眼看上去要让人有一种舒服的感觉！通篇一个方法是大忌，是绝对不允许的，尽量要将一些相关的代码抽成方法，将一些基础方法放到model类中复用。
其次，代码中变量的命名要清晰有意义，无意义的变量命名会让后来的代码维护者头破发麻，会让代码维护变得极为艰难，到时候可别怪人家问候你了。
然后就是注释了，这也是很重要的一点，一个优秀的程序员首先要学会写注释，一个会写注释的程序员不一定是一个好的程序员，但一个不会写注释的程序员绝对不是一个好程序员！
所以，判断代码好不好，就要从以上几个方面判断！
大家有什么看法，欢迎补充~
我是凉了个小秋，文青范的程序猿，欢迎关注，一起学习娱乐~
凉了个小秋
评判一段代码写得好不好，一般可以从以下几个方面来看：
1、代码书写是否符合业界通用规范，如PHP代码要符合PSR系列规范。
2、代码是否简洁，一段代码能用一行实现的尽量不要使用两行。
3、代码是否可重用，同一个功能尽量不要在多处重复书写。
4、代码是否安全，代码是否有考虑一些常见的安全问题和边界问题，如SQL注入、XSS攻击、CSRF攻击等等。
5、性能是否好，你写的代码最终是要运行的，如果性能不好，是会影响用户体验的。
编码之道
实际上也就是看程序员自己写的代码好不好，我觉得来衡量一段代码好不好的可以从如下四个方面去分析。
1、规范性。规范性包含两个方面，第一方面是：可读性，因为代码本身就是拿来读的，结果你搞了一大段代码，换个人去读你的代码，看了半天看不懂，那你说你自己的代码再好，估计也没人相信。第二方面是：就是一些变量名，函数名，类名等，比如Java里，都是驼峰型，英文叫camel-case，如isEffecitve这种；然后还有就是不要“中西结合”，即拼音英文结合，让人觉得非常鸡肋。补充一点，就是关于可读性，恰当的写注释，可能是一个比较好的idea。
2、效率。效率包含两个方面，第一点就是时间复杂度，其实这个问题非常常见。我举个小例子，比如，现在有一个需求，我们需要不断地insert和delete，那我们是选择ArrayList还是LinkedList呢，arrar删除和insert的时间复杂度是O(n)，但是LinkedList则是O(1)。这个时候我们肯定是选择LInkedList了，因为这种情况下，效率肯定是最低的。还有一种情况就是，冗余代码的情况，我们应该尽量不要在代码里写一些无关的代码，能简洁，就尽量简洁一些，起码看起来干净点，更舒服。
3、可扩展性。这个问题，就需要我们在写代码前，心里就应该对这块业务的代码的整体结构非常熟悉，需要考虑后续的一些业务扩展，需不需要改动非常多的代码。记住一句话，“面向接口编程”。
4、还有最后一点就是，格式。现在很多IDE都可以帮我们格式化代码，如果一段代码格式非常乱，我们读代码的人是非常痛苦的，如果你看过这样的代码，肯定是非常有感触的。
