风乱语

写了十多年代码，见过很多烂代码，也见过不少优秀的代码，那么如何判断代码的好与坏呢，我谈谈自己的看法。

好的代码，就算外行看到也会说是好代码

首先，好的代码会严格遵守代码规范。从代码的格式、命名、注释，就能看出来代码的好坏：遵守代码规范的代码不一定好代码，但好代码一定会遵守代码规范。

所以我经常说，好的代码，让一个外行人看，就算他看不懂写的什么，但是他也会说写的不错。

实现需求，并考虑可扩展性

代码必须要实现需求，这是及格线，对于好的代码，评定标准会更高。

举个简单的例子：

客户提了一个需求，查询展示客户列表，对于账户余额超过10万的客户，标红展示。

代码也很容易，余额>=10万{特殊处理}。

过几天，需求说，10万这个标准有些低了，变成50万吧。

然后改代码，余额>=10万{特殊处理}，然后上线。

又过了几天，需求说，50万有些高了，调整成30万吧...

如果把这个限额标准做成可配置的，是不是就灵活很多。（你要是把配置放在数据库中，每次判断去查询的话，你还是写死在程序里面吧）

我们圈子里就有一个传言：一个优秀程序员的品质，就是可以准确的蒙对客户要变化的需求。

注重业务功能，也要注重代码效率

工作十多年，我遇到很多这样的程序员：一心一意实现业务逻辑，在测试环境跑的没有问题，一上生产就卡死。因为测试环境有一千条数据，生产环境有一千万条数据。

所以好的代码，会根据实际生产环境的实际情况，进行一定程度的设计和优化。（优化是无止境的，适度就好）

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

会点代码的大叔

作为一名从事互联网行业多年的老程序员，我来回答一下这个问题。

在我看来程序员代码的好坏标准也与计算机行业的发展有密切的关系，早期的程序员非常注重代码的执行效率，比如时间复杂度和空间复杂度等，当前的程序员对代码的可读性和规范性也非常重视，因为目前的软件开发都是团队行为，团队合作一定要有规范性的代码要求。

我目前对团队程序员的代码要求主要集中在以下几点：

第一，代码的规范性。所谓代码的规范性指的就是代码的模块清晰、可读性强、格式良好、命名合理、注解详细。代码的好坏第一眼是模块划分是否清晰，然后是格式，再然后是逻辑是否清晰。如果这段代码执行的结果是正确的，但是逻辑混乱，这样的代码就不是好的代码，这也是很多初级程序员经常犯的错误，如果不及时指正，对他未来的发展会非常不利。

第二，代码的执行效率。代码的执行效率往往体现了一名程序员的能力，不同的代码在执行效率上差距非常大。代码的执行效率涉及到时间复杂度、空间复杂度，对算法的选择和实现思路决定了程序的执行效率。有经验的老程序员往往在执行效率上有多套完整的解决方案，这是年轻程序员需要重点学习和提高的地方。

第三，代码的扩展性。代码的扩展性主要体现在代码结构的设计上，运用规范的模式能够在很大程度上保证代码的扩展性。程序没有不修改的，修改就涉及到功能的扩展，而好的代码在功能扩展上就比较方便。比如在完成一个简单的数据存取功能的时候，程序员会按照实体类、接口、实现类、工厂类的结构来设计，这样以后的扩展会非常简单。

最后，不同的开发团队往往有不同的规范要求，程序员一定要仔细学习并掌握，这对以后的团队合作非常重要。作为软件团队的一份子，一定要记住不要犯低级错误！

我带软件团队多年，我会陆续在头条上分享一些开发方面的科普文章，感兴趣的朋友可以关注我的头条号，相信一定会有所收获。

如果有开发方面的问题，或者是考研方面的问题，都可以咨询我。

谢谢！

IT人刘俊明

程序员写的代码质量好坏可以从两个角度入手

1.好的代码一般通俗易懂

高手总会化繁为简，写的代码首先是能让人看懂，谷歌苹果的工程师代码提交之前都会找上周围的同时给看一遍，如果对方觉得没有什么问题可以直接提交，并且在提交注释里面写上reviewer名字，这样同时也把责任给担起来了，看似一个很简单的模式，却被绝大部分技术公司沿用。

所以代码不能只有自己能看懂，让别人能看懂你的思路，你的设计意图。

2.好的代码，遵守整个系统编码规范，不出格，最重要的一点好的代码能够经得起实践的考验，在实际运转过程中，没有很重大的系统崩溃出现才能称得上好代码

所以代码不能只是看着好，在性能上也需要有不俗的体现，对于程序员来讲代码就是脸面，特别是在团队配合之中，如果一个人写的代码质量高就会给人形成一种靠谱的感觉，在配合过程中也比较容易形成默契的感觉，一看谁写的代码如果平时代码质量高，大家在调用该模块的时候会觉得很舒心，很放心。代码直接关系着程序员的品质问题了，有很多老程序员对于代码质量非常关注，不允许自己犯一些很低级的错误，导致自己的名誉受损。

大学生编程指南

评判一段代码写得好不好，一般可以从以下几个方面来看：

1、代码书写是否符合业界通用规范，如PHP代码要符合PSR系列规范。

2、代码是否简洁，一段代码能用一行实现的尽量不要使用两行。

3、代码是否可重用，同一个功能尽量不要在多处重复书写。

4、代码是否安全，代码是否有考虑一些常见的安全问题和边界问题，如SQL注入、XSS攻击、CSRF攻击等等。

5、性能是否好，你写的代码最终是要运行的，如果性能不好，是会影响用户体验的。

编码之道

如何判断一个程序员写的代码好与不好？以下几个方案可做备选：

方案一：手写代码（好变态！！）

既然是码农，那么能有代码解决的事情绝对不用第二种方法。现在很多编程软件内部都有着相应的辅助填写功能，这反倒使得很多年轻程序员过于依赖程序辅助的同时放松了对基本内容的熟练。手写代码无疑最能考验程序员扎实的基本功底。

方案二：可以根据代码量与bug数量的增长函数来鉴别（当然不是绝对的）

刚入门的新人通常在代码量较少时bug的数量也少，但当项目复杂程度增长后bug数量会指数式爆发增长，普通水平的程序员自己写代码时bug数量和代码量呈稳定线性增长趋势，高级程序员bug量几乎不随代码量增长而增长。之所以说不是绝对的是因为还要考察问题的难易程度和解决问题的方法及效率。

方案三：综合代码能力的质问，易读？可拓展？数据灵活？可追踪？

很多程序员之所以喜欢写长代码，主要是写起来没什么障碍，也不用怎么思考，跟记流水账一样。还有就是学习的时候，养成了一些不良的编程习惯，亦或是习惯成自然，已经不知道自己所写的代码，是不是够简洁了。而真正优秀的编程高手总会化繁为简。所以代码不能只有自己能看懂，也要让别人能看懂你的思路和设计意图。

细腻独白

我想把这个问题转化为两个部分：第一个部分是怎么判断程序员的代码好不好，第二部分想说说什么样的程序员，才是好的程序员。

好的代码，就像是小说家手中的短篇小说，逻辑清晰，简单明了，却又能触动心灵，而坏代码，就像是一辆外表富丽的老旧汽车，开不动不说，随时还有散架的危险。

究竟什么样的代码才能算是好代码？这是一个很有争议的话题，每个人的理解可能都不一样，所以制定一个符合自己部门要求的规范，有了依据，写出来的代码才有可能成为好代码。

思考了一下题主提问题的场景，应该有两种情况。一种是，就是自己本身不懂代码，只是想知道怎么判断一个程序员的代码质量另外一种情况，自己本身就是程序员，可能是刚学不久，不知道怎么判断好代码的标准。

不懂代码，如何判断

如果你不懂代码，那就直接判断这个程序员是不是好程序员吧，判断代码，也不是你可以做的事。下面我会提到这一点。

好代码的判断标准

• 可读性
  

好的代码本身就是最好的说明文档——Steve McConnell

代码几千行，所有业务逻辑全部揉在一起，除了你没人看得懂，周末想续写代码，结果发现连自己也要看半天，才能接着写下去，这样的代码，能是一个好代码吗？

判断：将代码拿给其他程序员看，在读代码期间，他向你提出的问题越少，说明这些代码的可读性也就越强。

要想让部门所有人写出的代码可读性强，就必须制定一个统一的开发风格，这样不管是老程序员还是新程序员，都能快速上手，可读性也会得到一定的保障。

• 可维护性
  

曾经看过一段代码，一个method几千行代码，没有人敢维护，修改一点点就会发生不可知的错误，代码又臭又长，除了重构，完全没有办法。这样的代码，就是一个差到不行的代码。

判断：一般有三点可以做个大概的判断，一是易读，二是可拓展，三是数据灵活，四是可追踪。

• 简洁性
  

很多程序员之所以喜欢写长代码，主要是写起来没什么障碍，也不用怎么思考，跟记流水账一样。还有就是学习的时候，养成了一些不良的编程习惯，亦或是习惯成自然，已经不知道自己所写的代码，是不是够简洁了。

• 模块化
  

好的代码，都是模块化的。假设你的项目有三个不同的层，分别为内层、中层和外层。你的内容不应该从中层和外层那里导入任何东西。中层不应该从外层导入任何东西，这样做的好处是，你可以对代码的内层进行独立测试。

好程序员的判断

• 出货能力
  

写一个程序，算法非常精妙，代码质量也非常高，但产出效率非常低，也不能算是一个号程序员。之前我看过一个所谓的大神，算法很溜，但做事根本没办法按时完成进度，这也不行。

• 优化能力
  

没有一个程序，是一步到位的，很多时候随着业务的增大，对性能的要求越来越高，有一定的代码优化能力也是非常重要的。

• 调错能力

项目越大，遇到的bug会越力气，这时候就需要强大的debug能力，找出最为关键的错误点，甚至追溯底层框架的源码。

bug是不可避免的，但一个好的程序员，基本上不会因为代码数量的增多，而导致bug也同步增多，如果原本bug是10占1，后来代码增多了，变为100占3，而不是100占10.

• 技术掌控
  

你的项目能用spring，hibernate等等框架，但是对于这些技术，你真的掌控了吗？假如有一点，框架版本需要升级，你做得到吗？或者从hibernate转为mybatis？

剩下的，一些非技术相关的能力，比如学习能力、抗压能力，这里就不多说了。

——摘自W3Cschool学员的回答

W3Cschool

很多人不是天生就能写一手好代码，特别是刚开始工作一两年的程序员。如果公司不注重代码质量，只需要简单写下注释，没有代码review的喜欢，那提高代码质量全要靠自己了。

好的代码一般简洁，逻辑清晰，规范，设计模式运用得好。

一般公司会从你的代码质量评估你的个人能力，推荐看下阿里巴巴java代码规范，网上有相应文档，还有相关书籍，比如《重构改善现有代码设计》，《effective java》等书籍，对提升代码质量很有帮助。

Java资深研发

1.代码布局工整，这个应该都能做到。

2.模块化写代码，把一个个功能进行模块化，方便找bug和修复。

3.逻辑思维，逻辑好的可能几句代码就解决一个功能，但逻辑不好的可能需要几十行或更多的代码来实现，这个得多练。

4.底层知识掌握程度，这个会影响程序的崩溃，出错，卡顿，计算速度。底层知识过硬可以很好的避免。

5.多练可以提高效率和降低bug，如果是一个新手，一句代码几个十几个bug都很正常

梵蒂冈偷渡来的难民

实际上也就是看程序员自己写的代码好不好，我觉得来衡量一段代码好不好的可以从如下四个方面去分析。

1、规范性。规范性包含两个方面，第一方面是：可读性，因为代码本身就是拿来读的，结果你搞了一大段代码，换个人去读你的代码，看了半天看不懂，那你说你自己的代码再好，估计也没人相信。第二方面是：就是一些变量名，函数名，类名等，比如Java里，都是驼峰型，英文叫camel-case，如isEffecitve这种；然后还有就是不要“中西结合”，即拼音英文结合，让人觉得非常鸡肋。补充一点，就是关于可读性，恰当的写注释，可能是一个比较好的idea。

2、效率。效率包含两个方面，第一点就是时间复杂度，其实这个问题非常常见。我举个小例子，比如，现在有一个需求，我们需要不断地insert和delete，那我们是选择ArrayList还是LinkedList呢，arrar删除和insert的时间复杂度是O(n)，但是LinkedList则是O(1)。这个时候我们肯定是选择LInkedList了，因为这种情况下，效率肯定是最低的。还有一种情况就是，冗余代码的情况，我们应该尽量不要在代码里写一些无关的代码，能简洁，就尽量简洁一些，起码看起来干净点，更舒服。

3、可扩展性。这个问题，就需要我们在写代码前，心里就应该对这块业务的代码的整体结构非常熟悉，需要考虑后续的一些业务扩展，需不需要改动非常多的代码。记住一句话，“面向接口编程”。

4、还有最后一点就是，格式。现在很多IDE都可以帮我们格式化代码，如果一段代码格式非常乱，我们读代码的人是非常痛苦的，如果你看过这样的代码，肯定是非常有感触的。

张顾远

一个程序写的好不好，需要多方面考虑。

可读性。一个让别人看的非常费劲的代码不是好代码。也许自己过段时间也会看不懂。

健壮性。bug满天飞的代码，肯定不好。比如 "".equals(obj)绝对比obj.equals("")好。

扩展性。程序中不要有死代码。

关注我，每天两篇编程知识！

關鍵字: 科技 判断 代码