thfghfg

一段好的代码，最少要遵守基本的编程规范，比如命名方式，注视等等，就拿变量名来说，必须让人通过字面意思大概能知道这个变量是做什么的，代表什么意思，阅读性要好，否则其他人看到代码跟看天书一样，完全不知道是在做什么。同样的，方法命名也是一个道理。

以下图举例来说，两个方法都是检查用户名与密码是否为空，但是第一个方法明显规范于第二个方法，变量名就是账号与密码的英文单词，一看就明白，而第二个方法以a，b，c来命名，没人知道是啥意思，这种代码是最差的。

allen5168

编程界有句名言：“计算机程序是写给人看的，只是顺带计算机可以执行”。程序易读，没有花架子、没有不必要的提前优化，这是通用的原则。

但是在工程实践上，什么是好的代码，取决于代码满足要的需求的领域。

上图是一段摘自我个人项目的 C 语言代码（业余时间写作，非公司资产），可以看到用到了各种教科书都极力反对的 goto 语句，但实际上，如果是 C 语言比较熟练的话，使用 goto 语句可以大大简化函数返回时的清理代码，达到类似 C++ 语言 RAII 的效果。

再举个例子来说，当你的工作是实现一个被广泛调用的库函数，比如 C 语言 malloc 这样的内存分配函数，那么，速度和内存使用效率就是就是最大的需求，函数实现可以使用各种丑陋的优化技巧甚至内嵌汇编等等，但只要满足基本需求，这些破坏基本可读性原则的手段就不会影响你的代码成为一段好的代码。

在满足需求的前提下，我认为好的代码还符合以下特征：

1. 简单性：能用简单实现的方法就不要用复杂的方法，越简单的代码越容易维护；

   
   

2. 可读性：无论是作者还是他人，都能很容易通过阅读代码了解到代码实现的功能，且代码的编写没有违反常理的地方；

3. 分层与模块化：从架构的层面让代码易于理解与修改；

4. 优雅与简洁：代码在满足功能需求的情况下尽量采用成熟的算法与逻辑，举个例子，计算从 1 加到 100 的总和，优雅简洁的方法是使用等差数列公式求和而不是用循环累加；

5. 效率：一般来说符合上面4条的代码效率不会差，但也应把效率问题牢记在心，比如写 Java 程序，如果遇到多次字符串相加的情况，随时记得用 StringBuilder 来替换简单的字符串连接。

以上是个人对好的代码的几点经验，希望对大家有用。

命叔炸机

本人是软件行业从业者，也经常考虑这个问题，正好借这个机会说一下个人的一些想法。个人认为好代码，可能需要满足一下一些条件：

第一，实现功能，我认为这也是最重要的。如果你写的代码连最基本的功能都没实现，即使再漂亮再优雅，但一点实用性都没有，这点不满足的话，根本谈不上好代码。所以，我认为最大的质量就是实现功能，没有实现功能，其他的都是白扯。

第二，排版合理。必要的缩进、换行、空行、空格和括号的对齐要合理，代码有层次感。

第三、必要的注释。类注释，说明类的用途，类的作者，可能还有类的用法等说明。方法注释，方法用途，方法作者，继承说明，参数说明，返回值说明等等。变量注释，主要说明变量的用途。代码块的注释，简明扼要的说明代码的作用，让其他人清楚明白。

第四、合理的命名规则。类的命名、方法的命名、变量的命名要有意义，易懂。

第五、编码中需要注意的一些事项和遵循的原则。比如输入流和输出流的关闭，需要在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最好

四、学习习惯

大黄哥儿

一个非常好的问题，我是工作多年的Web应用架构师，来回答一下这个问题。欢迎关注我，了解更多IT专业知识。

通用规则：实现功能、健壮、简单、易读、易维护。

详细规则：见仁见智，可参照一些业界常用规则。

反面规则：《垃圾代码19条法则》

急速马力快de源码客

好代码，满足两个条件：能实现预定效果、能被人容易看懂。

代码的差别，不在于能否实现功能，更主要是实现的好坏。

有些代码虽然实现效果了，但换个程序员就看不懂，无法维护，也是烂代码。

现在的软件业，程序员加班都是普遍现象，疲劳工作，势必影响代码质量。

大部分都在着急实现功能需求，完成领导安排的任务，只是以完成为目标。

这种不考虑长远的工作方式，虽然短时间内达到了目的，但长期看问题很大。

程序员一旦离职，新来的需要花很久才能接手，项目的扩展性和稳定性都没保证。

尤其一些外行的领导，一味地只知道做出来给上级邀功，不能科学的排期。

功能需求说改就改，新功能拍脑袋就来，导致项目设计不断调整，损伤整体的架构稳定。

整个行业还没意识到代码质量的重要性，对代码没有敬畏之心，只看眼前不顾长远。

只有行业人员达到饱和，把不合格的程序员和产品经理都淘汰下去，好代码才能形成风气。

台哥彩铃

在我看来，好的代码分成这几个层次：

实现功能（需求）

单纯的把需求实现，只能算“合格”的代码，如果要成为（初级）好代码，我认为还需要做到下面几点：

• 代码的健壮性：需要多考虑规范要求以外的可能，我经常对组员说“不要相信别人，我们要把自己的代码考虑全面”；比如开发一个接口，双方已经约定某个字段是必传的，那么是相信对方系统会传这个字段，还是“不要相信对方”，接口中增加非空判断。

• 代码效率：在工作期间，我发现很多开发人员很容易犯的一个错误，就是只关注功能的实现，而不会考虑代码执行效率；例如测试环境数据库中有一万的数据，随便写个SQL也不会发生效率问题，但是生产环境一千万的数据，代码一上生产就会出现问题（项目最好能提供一个准生产环境，或者生产环境的试运行）。

让别人能看懂

一方面，软件开发需要团队合作，另外一方面，程序员岗位的流动性比较强，可能两三年过后，项目组成员已经完全换了一拨人了；所以代码容易阅读，是很重要的。

• 遵守代码规范：代码分层、起名见名知意、代码样式等等；

• 准确的代码注释，接口必须有接口文档；代码修改之后，对应的注释和文档必须也对应修改；

少些代码

少些代码不代表让你偷懒，要想写出【好代码】，一定不能只【看到代码】。

• 深入了解需求，不合理的需求或者重复的功能，可以拒绝，或者给出其他的建议；
  

• 设计和写代码的时间投入，一定要合理安排，甚至有些时候，设计的时间翻到更长；

• 能复用的尽量复用，能抽象的尽量抽象，以便以后可以复用；

• 如果有经过实际考验的【轮子】，那就直接拿来使用；

• 时刻要注意“过犹不及”：千万不要学了什么新的技术（框架、设计模式等），一定要用到项目中，而不是考虑是否合理，是否适用。

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

会点代码的大叔

对于一个程序猿来说，是必须要有评判代码好坏的能力的，如果连评判代码好坏的能力都没有，那怎么能写出好的代码呢？对于代码评判的好坏，其实也就是对代码质量的评价

如何评价代码质量的好坏呢

平常评价代码的好坏都会用到哪些词汇呢，可扩展性、稳定性、可维护性、可读性、可读性高、可测性好、高内聚低耦合、稳定性、安全性、鲁棒性等等，听过的没听过的还有好多。其实了解的人知道这些词汇都是从代码的不同角度去说的，所以评判代码应该从多个维度去说明。

常见的评判代码质量的维度

• 可维护性

• 可扩展性

• 可读性

• 灵活性

• 简洁性

• 可复用性

• 可测试性

对于一段代码函数或者类，为其编写测试代码的难易程度，或者编写单元测试很困难，需要用到框架的高级特性才能实现，就叫做代码的可测性。比如滥用静态方法，耦合程度过高，使用复杂的继承关系，滥用可变全局变量这些都是可测性差的代码。

如何写出高质量的代码

要写出高质量代码，需要掌握更加明确细化的编程方法论，包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。

测试轩

面对这个问题，可能大多数程序员想到的是：高内聚，低耦合，可维护，易扩展。这些是对的，对于大部分IT从业者（尤其是刚入行，缺乏足够知识和经验的新人）来说，并不能通过一个具体的标准去衡量。

什么样的代码才是好代码？衡量代码的好坏的指标或者维度有很多，比如性能好、架构好、高内聚等，这些指标的侧重点各不相同，不同的开发人员的关注的重点也各不相同。

一方面是缺乏编程方面的经验，在写代码时考虑的不够全面，另一方面也有可能是需求的更改导致代码的变动，这些都能影响代码的质量，而代码的质量会影响到产品的性能和好坏，接下来笔者与大家分享一些优质代码的标准。

优质代码就好比一本书，主旨贯穿全文，容易理解分章明确，要想写出好的代码，需要满足以下标准：

1.明确性 ------ 代码能够做到不解自明。

2.可读性 ------ 让其它开发人员能够看懂。

3.简洁性 ------ 减少不必要的冗余。

4.效率性 ------ 使代码运行速度快。

5.维护性 ------ 容易修改升级。

一、代码标准

1 明确性

明确性，质量较好的代码，逻辑性相对比较的清晰，bug难以隐藏。要知道你所写的每一段代码是要干什么用的，有目的的去编写程序，使程序整体有逻辑，在一些方法和属性的命名时，尽可能的给予明了易懂的名称，就像方法名采用动名词组合一样，从而提高可读性。

2 可读性

软件开发往往不是一个人就能完成的，需要团队的通力合作。可读性，不只是你自己，还要让其他开发、测试和运维人员能够对所写的代码一目了然，尽可能的减少或不写注释。在出手之前先思考，不要写出自己所不能理解的代码，那样只会加速系统的腐烂，做为一名程序员很有必要对自己所写代码进行思考和理解，从而对代码进行整理提高简洁性，好的代码本身就是最好的说明文档。

3 简洁性

代码中类和方法的长度要相对简短，简短的代码活的更长久，没有程序员不喜欢简短的代码，而且这样出来的产品问题相对就会较少。

在一些方法中我们可能会遇到方法体过长的情况，一般来说高效的方法它的方法体不会过于太长，而太长的方法体，我们从中将其抽取分为两个方法来进行调用，并且修饰符应该为private不能公开化，这样做不仅能划分业务逻辑，还能减少阅读压力，美化代码，在下面样例中如果不将方法体进行拆分，那么代码就会变得很臃肿，阅读压力大大增加，而进行规划拆分后，就能很清晰明了的阅读：

4 效率性

效率性，从一开始就要考虑程序性能，不要期待在开发结束后再做一些快速调整，在满足正确性、明确性、可读性等质量因素的前提下，设法提高程序的效率，在程序执行时让代码的执行速度较快，应以提高程序的全局效率为主，提高局部效率为辅。

5 维护性

所谓的维护性，就是指在系统发生故障后，在排查改正、改动、改进时的难易程度，维护性实际上也是对系统性能的一种不可缺少的评价体系。保证你所写的代码维护性相对较高，让你和其他人修改起来比较简单，而不是牵一发而动全身。

6、命名

命名在一个项目工程中也影响着代码的好坏，无论是包名、类名、方法名、变量名,命名的时候都应该考虑周全，实际开发过程中，我们的工程通常都会进行分包，其中一个功能模块可能是一个或多个包组成的，这也就要求我们对包进行划分同时还要规范命名

二、架构设计

1、代码的高内聚

内聚是从功能角度来度量模块内的联系，代码关联性比较强的代码应该放在内聚在一起，形成一个独立的功能模块，可以是一个独立的类，也可以是一个微服务。其实判断代码是否内聚一个比较简单的方法就是看你能否给代码或者服务给一个贴切的名字，如果代码功能不内聚，我们是很难用一个简短的名字来表示它的含义的。

2、代码的低耦合

耦合性(Coupling)，也叫耦合度，是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。

耦合比较高的代码危害比较大，最常见的表现就是改一个模块的代码会影响许多其它模块，最终必然导致大家不敢修改旧的代码，只能不停的添加新的接口，系统的可维护性非常差。

三、好代码好处

1.功能模块相对完整独立，实现的逻辑性清晰，可读性强。

2.多人合作开发的分工更加明确，开发速度较快，同时软件质量高。

3.可以将模块公用接口提升，充分利用可以复用的代码。

4.可维护性强，避免修改一处代码牵扯许多模块，容易控制。

IT老田

代码的本质还要在机器上运行，好的代码不单单的纯粹的简单的几个字符的问题，好的代码不仅仅是排版上或者语法上好看，还要能经过产品的测试验证，这是评判代码好坏的最准确的标准。不同水平的人对代码的理解是不一样的，现在就是三种水平的人分析对待代码的不同态度，代码能够在表面上看到水准，深层次只能靠实践验证。

在初级程序员的眼里代码就是天了，能够用代码实现领导布置的技术任务，就是最大的满足了，几乎所有的精力都在代码上体现出来，拿到需求的第一时间就是会问自己代码如何去写，是不是会写，如果不会写该怎么办，这也是通常刚入门的程序员要克服的事情，这个阶段对于程序员的要求过多也不是很现实，毕竟刚开始还在解决温饱阶段的时候，不能强求吃的非常奢侈，而且这个阶段的程序员能够实现一个基本功能就能获得巨大的成就感，每个阶段追求的层面不一样，代码的严谨程度实现方式等等都是存在巨大的优化空间，甚至还有一些废物代码都是存在的。

中级程序员已经能够对代码有基本的掌控能力了，拿到需求之后已经开始考虑用什么方式实现起来更加稳定可靠，这个阶段的程序员编码水平属于基本功能做的可靠扎实，已经能够驾驭代码了，拿到需求之后不是先问代码如何实现，而是会从试下上看看有没有更好的实现方式，绝大多数程序员属于这个水准，基本上也会分成以下几种情况，看到差不多的功能从网上找对应的代码，看明白之后直接拷贝过来修改成适合当前框架的代码风格，这个时候的程序员普遍上已经对编程有了感觉，觉得编程也就是这么回事，很多程序员这个时候放松了对自己的要求，不像刚入行那种诚惶诚恐的样子了，越是这个阶段越是要保持一种前进的动力。因为很多年龄大的程序员后面跟不上节奏了，就是从这个阶段开始的。

高级软件工程师对于代码的依赖性更少了，考虑不仅仅是实现功能问题了，拓展性兼容性以及跨平台都是在考虑的范畴，甚至还会考虑轮子的使用是不是靠谱，还有再优秀点就考虑如何造轮子，即使造不出来也会尝试去积累经验，毕竟不是每个人都能有机会架构一个框架，但起码在平时的工作过程中会一直准备着，所以等到有了机会之后紧紧抓住，现在能成为架构师的人基本上都是这么出来的，说到代码就会涉及到编程语言的范畴，编程语言也好代码也好都是工具般的存在，工具就是为框架服务的，基本上这个层面的程序员是用这种方式对待代码的。

当然基本的代码需要好的规程规范，需要遵循基本的编程语法，起码让人能看懂，如果一个人写的代码只能自己看懂，这属于比较失败的程序员，越是复杂的功能通过代码的实现变得简单化，这才是程序员追求的目标，现在几乎巨头公司都有自己的编码规范，就是制定一个统一的标准方便程序员去编程，对于代码来讲一年不懂可以两年甚至三年早晚能够搞明白。编程思想的锤炼才是高手的晋级之路。

關鍵字: 命名 科技 代码