【编码规范】从代码之丑聊代码规范

最近看了代码之丑，就打算整理下，总结一下。

代码命名

首先从命名来说的话，其实对于大多数程序员来说，可能基本都是翻译软件翻译下，然后就直接改成对应的类名、参数名、函数名等。其实仔细一想，命名其实是很重要的。作用要做到简明之意。比如说针对一块三方数据调用的逻辑，那么就可以记性抽象化，然后callXXXThirdApi()，或者工具包的时候，要起到别人不看内部细节，就大概可以知道具体的作用。

好的命名，是体现业务含义的命名

重复代码

重复代码其实在项目中可能随处可见，写代码要想做到 DRY，一个关键点是能够发现重复。而不要重复是一个非常重要的软件设计原则，我们需要善于发现重复的代码将其改造成一个可以复用的代码逻辑。
比如针对于三方调用，对于接口超时重试机制，就可以进行封装成一个类。供系统内部所有调用外部系统使用。
不要重复自己，不要复制粘贴。DRY (Don’t Repeat Yourself)

长函数

长函数主要就是针对一个100多行的代码处理的功能过多，导致所有业务都冗余在一起，这种情况下，我们需要按照单一职责进行划分，按照不同的功能模块进行抽取出来。提取函数。
函数写短，越短越好

大类

大类其实和上面的长函数是同样的原因，就是职责划分不清楚，一般来说，一个类的也只应该负责一件事情，即便是通过继承和组装的方式。
把类写小，越小越好

长参数列表

减少参数列表的，如果过多就进行抽取出来形成一个类，然后进行传输。并且对于程序中 出现标记的行为 一般也不建议。

滥用控制语句

if\else 循环语句，可能有时候会导致代码层级太深，容易出现逻辑问题，所以针对这种情况，if情况不要多层判断，而要通过直接返回不符合的条件。直接return/。

缺乏封装

封装和抽象还是很重要的，如果一个业务功能都是由面条式的代码进行构建，那么无论在代码构件上还是业务逻辑以及后期的维护阶段成本都是显著增加的。一般可以运用迪米特法则。构建模型，封装散落代码。

依赖混乱

在面向对象中有一句话，那就是面向接口编程，高层依赖抽象，细节依赖于抽象。高层->抽象->细节。这样的架构是比较稳定的。

CR

CR的过程 可以尽可能暴露问题，以及可以提升自己的技术，本质上就是将自己的对代码的理解进行复述出来，然后其他人针对代码细节进行输出自己的建议。1.可以发现业务流程上的BUG 2.代码技术实现上的差异 3.代码的不规范地方。

最近感悟越来越深了，那就是好的编码习惯可以从一定程度上减少BUG数。并且前期的设计考虑的越多，后期出现的问题就越少。所以作为程序员 我们在实现需求的时候，不能仅仅是实现需求，需要从多个角度去考虑需求的合理性、需求的可实现性、以及在功能实现上的具体方案和细节、编码、测试、上线、监控等。