代码整洁之道cleancode
软件功能实现是最基础的，代码整洁，⼯具美观也很重要。以下为代码整洁之道笔记：
命名：
    1、有意义，名副其实：降低代码的模糊度，明确说明代码的⽤途；
2、避免误导：accountList的类型最好就是List；
3、避免使⽤多个不同之处较⼩的名称；
4、避免使⽤字母l和O，因为它们像数字1和0；
5、做有意义的区分，只有意义不同时才使⽤不同的名字；
6、废话是⽆意义的区分，是冗余；
7、使⽤可搜索的名称：⽤宏定义数字⽐直接⽤数字好，避免使⽤单字母变量和数字常量；
8、不必使⽤带类型的匈⽛利标记法；
9、避免成员变量使⽤类名前缀；
10、类名和对象名⼀般都是名词和名词短语；
11、⽅法名⼀般是动词和动词短语；get,set,is前缀；
12、使⽤解决⽅案领域内的名称；
13、添加有意义的语境：使⽤有意义的前缀，创建⼀个类并将变量声明为成员变量；
14、命名要精确：不要添加⽆意义的语境；
函数：
1、短⼩：函数中的缩进层级不应该多于⼀层或者两层；
2、函数应该做⼀件事，做好⼀件事，只做⼀件事；
3、每个函数只有⼀个抽象层级，其他的交给下⾯的抽象层来做；
4、判断函数只做了⼀件事：不能分函数区段；
5、阅读代码，⾃顶向下规则：每个函数后⾯都跟着下⼀个抽象层的函数；
6、如何让switch只做⼀件事：通过类⼯⼚创建实际类并返回⽗类引⽤，再使⽤抽象类（⽗类引⽤）调⽤实际类重写的函数；
7、使⽤描述性的名字；
8、函数参数：为了便于测试，应该少于2个；
9、⼀元函数的3种形式：
      ①询问关于参数的问题（判断），②转换参数的内容（要有返回值），③参数是个事件（⽆返回值）
10、如果函数超过2元：应该将其中的某些参数封装成类；
11、函数名字：动/名词形式；
12、避免使⽤输出参数：如果需要，应该修改所属对象的状态；
13、⼀个函数要么做⼀件事（指令），要么回答⼀件事（询问）；
14、使⽤异常代替返回错误码：这样错误代码可以从主路径代码中分离出来，避免嵌套；
15、分离try/catch块：集中在⼀个函数中；
注释：
  1、整洁清楚的代码⽐注释要好得多；
  2、真正好的注释就是考虑不⽤写注释；
  3、需要注释的地⽅：提供法律信息；解释⽅法的意图；提供警告信息；
  4、  ToDo注释，提⽰尚未完成的⼯作；
  5、避免括号后⾯的注释，应当减少嵌套，写成⽅法；
  6、删掉被注释掉的代码；
  7、注释就是⼀种失败；
格式：
  1、垂直上的间隔：不同的逻辑之间⽤空格间隔；
  2、垂直上的靠近：关系密切的逻辑要靠近才会更加清晰；
  3、变量在离使⽤最近的地⽅声明；
  4、相关函数：放在⼀起，调⽤者放在被调⽤者的上⾯；
  5、概念相关：命名模式相同，应该放在⼀起；
  6、⽔平⽅向：以不拖动滚动条为准则；
  7、  =，+=等前后的空格可以起强调的作⽤；
  8、缩进
  9、团队规则
对象和数据结构（过程式代码）：
  隐藏实现关乎抽象，并不是简单的添加取值器和赋值器；
抽象类的使用  1、对象和数据结构的反对称性：
    过程式代码便于在不改变既有代码的同时，添加新的函数（过程）；
    ⾯向对象便于在不改变既有函数的情况下，添加新的类（对象），但是如果抽象类添加新的函数，就需要修改抽象类的所有⼦类；
  2、数据结构应该只有公共变量；对象应该只有私有变量和公有函数；
  3、对象暴露⾏为，隐藏数据；便于添加新对象类型⽽⽆需修改既有⾏为，同时也难以在既有的对象中添加新⾏为。
    数据结构暴露数据，没有明显的⾏为；便于向既有数据结构添加新⾏为，同时也难以向既有函数添加新数据结构。
4、The law of demoter : 模块不应了解它所操纵对象的内部情况。⽕车失事，混杂，隐藏结构。
错误的处理：
  1、不要返回null值：这样的话调⽤者就要处理null，增加⼯作量；
    解决：抛出异常或者返回特例对象；
  2、不要传递null值：
  3、异常的处理：抛出异常或者返回特例对象；如果是调⽤第三⽅api可能产⽣异常，可以新建⼀个⽅法或异常类将第三⽅api打包；
  4、避免使⽤可控异常（checked exception）：因为处理它们需要修改函数头，违反了开放-闭合原则；应该使⽤不可控异常（runtime exception），
保持边界整洁：
  1、学习性测试：在项⽬中引⼊第三⽅api的新版本，测试项⽬是否正常⼯作；
  2、处理边界问题⽅法：⽤新类包装第三⽅api；⽤adapter模式将我们的接⼝转换为第三⽅提供的接⼝；
单元测试：
1、测试驱动开发，整洁的测试有助于进⾏代码的改动；
  2、整洁测试的标准：可读性；
  3、双重标准：由于运⾏环境的差异，测试代码和⽣产代码可以有不同的标准，如效率、内存等；
  4、单个测试的断⾔数量应该最⼩化，只测试⼀个概念；
  5、F.I.R.S.T规则：
    F fast：测试需要频繁运⾏，因此要能快速运⾏；
    I Independent：测试应该相互独⽴；
    R Repeatable：测试应当能在任何环境中重复；
    S Self-validating：⾃⾜验证，测试应该能看到成功与否的结果；
    T timely：测试应该及时编写，应该恰好在⽣产代码之前编写；
类：
  1、类的组织：⾃顶向下原则，变量列表（公共先于私有，静态先于实体），⽅法列表（⼯具⽅法紧跟在所属⽅法之后）；
  2、类应该短⼩：类名越明确，类的职责就越清晰；
    （1）每个类单⼀权责，只有⼀个修改它的原因，并与少量的其他类协同完成⼯作；
    （2）内聚：类中含有最少的变量，且每个⽅法都使⽤每个变量，此时内聚度最⾼，类应该是内聚⾼的；
  3、隔离修改：具体类实现细节，抽象类只呈现概念，利⽤接⼝和抽象类可以隔离因为细节的改变⽽带来的改变类的风险；
系统：
  1、构造与应⽤代码应该隔离开：就好像建设⼤楼时，构建⼤楼的吊车、铲车之类的东西，在⼤楼投⼊使⽤时已经完全不存在⼀样；软件系统应该讲启动过程和启动过程之后的运⾏时逻辑分开，在启动过程中创建应⽤对象，也会存在相互的依赖。
    public Service getService(){
      return new MyServiceIml(...);
    }
    这种延迟化赋值的好处是：在使⽤对象之前不⽤关⼼这种架空构造；坏处是：必须实现这个构造⽅法，不然⽆法编译，即使这个对象在运⾏时永远不会被使⽤。
  解决⽅法：
  （1）分解main，将系统中的全部构造过程搬迁到main或者main模块中：main函数创建对象，再将对象传递给应⽤，应⽤直接使⽤；  （2）⼯⼚，可以让应⽤控制实体创建的时机；
  （3）依赖注⼊，控制反转IoC是依赖管理的⼿段，它将应⽤需要的依赖对象的创建权责从对象中拿出来，放在⼀个专注于此事的对象中，并通过依赖注⼊（赋值器）将依赖对象传递给应⽤；
  2、扩容
  AOP，⾯向⽅⾯变成。Java中三种⽅⾯和类似⽅⾯的机制：代理，纯AOP框架，AspectJ
    （1）Java代理：wInstance(被代理接⼝，InvocationHandler h)⽅法执⾏后，被代理类的所有⽅法都会被加上Handler的处理逻辑，这是简单的AOP，但是太复杂；
    （2）纯AOP框架：Spring AOP（需进⼀步了解）
    （3）AspectJ语⾔
  最佳的系统架构由模块化的关注⾯领域组成，每个关注⾯均⽤纯Java对象实现。不同的领域之间⽤最不具有侵害性的⽅⾯或类⽅⾯⼯具整合起来。这种架构能测试驱动，就像代码⼀样。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。