风乱语

由题目审题得知：评判对象为程序员，评判内容为其下的代码；

那么在没有明说初级程序员、高级、资深，还有具体技术定向的情况下，提问者应该就是问的针对编程这项工作而言，具有普遍通用的评判标准：下面就来列几条具有普遍适应性的评判标准：

1、代码注释：这一点是很简单的一点、也是适用性很强的一点；无论是个人编程还是公司业务、核心技术研发、科研等等类型的项目都需要，好的注释会使得代码可读性强，易于代码的交接、复用。

2、命名规范：命名规范，有文档的、项目的、资源文件的、类的、函数的、变量、常量等等，之所以放到第二位是因为，适用于代码的好的命名规范，一般具有唯一性（不会产生歧义），专业性、简洁性等特点，能让项目代码协同工作人员一眼读懂其所代表的含义，在相同作用域下不会与类似作用功能的函数、变量等，产生命名冲突和歧义。

3、编程风格：编程风格大公司一般都会有具体要求，其中命名规范也是其中一点；拆开讲是为了内容简洁;简单讲几点：1、代码对齐格式 2、函数{}的使用，代码段的设置 3、字符串、sql语句的编写规范 4、返回值，函数类型（这个放进来比较勉强）5、如果再往大了说，文件组织等（偏向于架构风格）

4、代码性能：也可以说是代码执行效率；这个就得视具体项目及应用环境的限制了，主要还是看在空间利用率和时间执行效率上的性价比。

5、耦合性：特别是业务型的项目很注重，现在普遍采用微服务的架构模式，主要也是为了满足低耦合的要求；代码耦合性高，会造成可维护性特别差！包括对代码的业务/功能拓展，性能优化、重构等等。

6、复用性、可移植性：一个偏向于（Java、.net等）一个偏向于c一类的编程语言及技术；复用性需要做好低耦合比较容易达到，如：减少对输入参数、输入参数类型申明为泛型、返回值类型返回泛型等。可移植呢：多用于嵌入式移动设备的底层编程、驱动、内核、网络、文件等底层架构基础编程。

这几点可能不全，但是基本做到了能较为普遍的覆盖大多数的代码评判标准了。

清风竹下岁月

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

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

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

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

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

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

举个简单的例子：

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

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

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

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

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

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

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

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

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

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

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

会点代码的大叔

我来说说我在工作中遇到的一个例子，某天因为业务需要，要修复一个bug，找到bug相关代码，一看代码，差点把我吓死，大家猜猜怎么着？一个定时工作的job类，五百多行代码，只有一个方法，代码中命名混乱，各种不在一个抽象层级的代码混杂在一起，更让人气愤的是全篇没有一行注释！一看到这种代码，就没一点心情看下去了，奈何bug要修复啊，只能硬着头皮看了，最后花了好长时间才找到问题原因，将bug修好，而我已经早已头昏脑胀，不知道问候过多少遍这个奇葩的前辈了。

看完我这个实实在在的例子，要如何判断一个程序员写的代码好不好，其实已经很清楚了！

首先要有完整清晰的代码结构，起码要一眼看上去要让人有一种舒服的感觉！通篇一个方法是大忌，是绝对不允许的，尽量要将一些相关的代码抽成方法，将一些基础方法放到model类中复用。

其次，代码中变量的命名要清晰有意义，无意义的变量命名会让后来的代码维护者头破发麻，会让代码维护变得极为艰难，到时候可别怪人家问候你了。

然后就是注释了，这也是很重要的一点，一个优秀的程序员首先要学会写注释，一个会写注释的程序员不一定是一个好的程序员，但一个不会写注释的程序员绝对不是一个好程序员！

所以，判断代码好不好，就要从以上几个方面判断！

大家有什么看法，欢迎补充~

我是凉了个小秋，文青范的程序猿，欢迎关注，一起学习娱乐~

幻境少年

1 ：好的代码看起来就像艺术品，能给读者一种很舒服的感觉。

2：特别符合代码规范，该缩进的地方要缩进，字母大小写要遵守，变量采用大驼峰还是小驼峰要统一。

3: 可读性强，函数功能要有说明，传入参数传出参数含义和格式要明确，都要有备注；变量定义呀函数名称呀更要可读，类似isDIgit判断是否是数字，就非常的易读好记。

4：健壮性要强，比如对于输入的变量要检查，异常情况要考虑全，不能 core掉。

古城老王

代码好与不好，要看代码在实现功能的同时，能不能很好的支持后面功能的维护和扩展。这里涉及到代码设计的6大基本原则：

1. 单一职责原则

一个类或者一个接口，最好只负责一项职责

2. 开闭原则

一个软件实体如类、模版和函数应该对扩展开放，对修改关闭

3. 里氏替换原则

原则包含了一下四层含义：

- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；

- 子类可以增加自己特有的方法；

- 当子类的方法重载父类的方法时，方法的形参要比父类方法的输入参数更佳宽松；

- 当子类的方法实现父类的抽象方法时，方法的返回值要比父类更加严格；

4. 依赖倒置原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象，其核心思想是依赖于抽象；

5. 接口隔离原则

一个接口只服务于一个子模块或业务逻辑，服务定制。也就是说建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。

6. 迪米特法则

一个对象应该对其他对象保持最少的了解。就是一个对象对自己需要耦合关联调用的类应该知道的少；这会导致类之间的耦合度降低，每个类都尽量减少对其他类的依赖

除了上述所说代码设计的几大基本原则外，还有以下代码习惯需要遵循：

1. 注释

代码首先要尽量具备自注释功能，如果确实无法自注释，需要增加必备注释，减少废话注释；

代码注释需要随着修改而更新。

2. 命名和格式

遵循统一的命名风格，统一的缩进格式，代码一目了然，阅读代码也会无比舒心。

3. 团队协作

团队协作项目中，尽量使用常用的用法，不影响效率的情况下，尽量减少太高级的用法。

4. 架构和解耦

大型工程，架构和解耦非常重要，使用合理的架构，将功能模块化，扩展和维护，只需要修改对应的模块和文件。

代码猩球

Java程序员中非常流行阿里巴巴Java编码规范，这是阿里对Java程序员的规范要求，一公布引起很大反响，笔者作为把阿里规范看了不下五遍的人，不得不承认如果代码能按照编码规范来写，那将是非常优秀的。不仅仅是影响了代码的整洁度，有些规范的编写将非常有利于软件的性能和稳定性。

判断代码好坏我有以下几个方法:

1. 首先先看代码的规范性，比如驼峰写法，比如是否在每个接口处都带有注释。这些可以用阿里插件扫描。
   
2. 其次，可以用sonar等工具进行扫描，看看代码是否有空指针的可能性，还有些“坏味道”的代码。
   
3. 最后，可以看看这些代码的细节，具体实现方式，在核心算法里有没有注释，是否冗余，是否会有更好的写法替代。
   

极客宇文氏

好的代码简单明了，逻辑清晰，那么好的代码规范要求如下：

1、代码是否符合业界通用规范，如Java语言的标识符的命名规范

1)、变量、方法：

1)、单个单词：全部小写

2)、多个单词，首单词小写，其后的单词首字母大写，小驼峰标识

2)、类、接口： 所有单词首字母均大写，大驼峰标识

3)、包：小写字母组成,域名反着写

4)、统一的缩进

5)、变量、方法、类命名要见名知意

6)、良好的注释

7)、大小写敏感问题

2、可读性强：

3、代码是否简介，一个代码能用一行的尽量不用2行

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

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

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

梦豆PS设计分享

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

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

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

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

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

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

大学生编程指南

理论上讲，好的代码要简洁，逻辑清晰，易扩展，良好的封装等等。

但在实际中，吐槽代码已成了程序员的日常。

借用亚马逊工程师的话，来形容说他们的代码:“一座很大的屎山，你见过的最大的山，每次你想修正一个bug，你的工作就是爬到屎山的正中心去”。

我们组曾有一个著名的6000行后端JS，没有面向对象封装，纯靠函数。 其中有好几个上千行的函数，带了二十多个形参，几个标志位，分别有十几个数字状态。注释？没有的。

每一个接手过这段代码的人都会不约而同的发一条朋友圈以示佩服。

但神奇的是，代码在执行上基本没太多的错。

直到几个月前，一个大牛在走之前把这段代码全部重写了一遍，留下了至今都没有改完的bug。

非著名程序猿

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

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

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

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

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

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

關鍵字: 评判 科技 程序员