标签：apu   center   ssr   depend   tin   签名   打包   isp   好的   

代码整洁之道

前言

如何用功

  阅读大量代码

  找优点和缺点

第一章 整洁代码

不要留到以后，稍后等于永不

烂代码影响生产力

代码整洁性不但有关效率，还有关生存

好代码

  C++之父

   尽量减少依赖关系，便于维护

   性能调至最优，防止修改导致混乱

   分层战略完善错误处理代码

   代码逻辑直接了当 叫缺陷难以隐藏

  破窗理论

   破损的窗户开辟了大厦走向颓废的道路

  只包含必须之物，果断决绝

  TDD 有单元测试，验收测试，少的依赖关系，少的API

  越小越好

  少的代码重复

童子军军规

  让营地比你来时更干净

第二章 有意义的命名

名副其实

  不要有魔数数

避免误导

  最好不用List的容器名字如accountList

  避免使用不同之处较小的名称

  避免使用 O o 0 l 1这种字

做有意义的区分

使用读得出来的名称

使用可搜索的名称

避免使用编码

  不要使用 IShapeFactory 不对接口编码

  对实现编码 如ShapeFactoryImpl

避免思维映射

  不应当让读者在脑中把你的名称翻译为他们熟知的名称

  明确是王道

类名

  是名词或名词短语

  避免使用Manager Processor Data Info 类名

  重载构造器时，使用描述了参数的静态工厂方法名

每个概念一个词 get fetch

避免双关语 一词多义

第三章 函数

短小

  函数不该长于一屏幕

  20行封顶最佳

  if elese while 语句 代码块应该只有一行

只做一件事

  判断是否做了一件事，就看能否在拆出一个 函数，该函数不仅只是单纯地重新诠释其实现

  如果一个函数只是做了该函数名下同一抽象层的步骤，则还是租了一件事

每个函数一个抽象层级

使用描述性的文字

  命名方式保持一致

   讲出一个故事

抽象工厂代替switch语句

函数参数

  最理想是零参数

  尽量避免三参数，有足够理由才能超过三

  尽量使用返回值，而不是输出参数 如 void transStringBuffer out)和 StringBuffer trans(StringBuffer in)后者好

  不应该使用表示参数，如 render(true) 应该使用两个独立的函数替换

  二元函数要付出代价，可以通过成员变量，抽象出新类来避免

  多个参数，应该考虑参数对象

  不能有副作用

   不能产生其他潜在操作

  分隔指令与询问

   要么做什么事，要么回答什么事，不能兼得

使用异常替代返回错误码

  错误处理代码从主代码路径中分离出来

不要重复自己

如何写函数

  先写，打磨，分解，修改名称，消除重复

第四章 注释

注释恰当用法是弥补在用代码表达意图时遭遇的失败

花时间清洁代码，比写注释要好

很多时候，简单到秩序创建于注释描述一致的函数

好注释

  法律信息

  提供信息的注释

  对意图的解释

  警示

   大型操作

   一般使用 @Ignore 关闭测试用例

坏注释

  喃喃自语

  多余的注释

  误导性的注释

  循规式的注释

  日志式注释

  废话注释

  能用函数活变量就别用注释

  括号后的注释

   如 } // try 等

   应当缩短函数，重构代码

  归属与署名

   应该依赖于源代码控制系统

  注释掉的代码

第五章 格式

格式的目的

  代码可读性影响到可维护性和扩展性

垂直格式

  短文件比长文件易于理解

  向报纸学习 有大纲 由浅入深 不长

  每组代码有一个空格，层次感

  垂直方向上区隔的作用

  垂直方向上的靠近

   紧密相关的代码要靠近，而不能用注释隔开了

  垂直距离

   本地变量应该靠近其使用位置，在函数顶部

   实体变量应该在类的顶部声明

   相关函数

    某函数调用另一个函数，应该放在一起

    调用者在被调用者上面

   概念的函数应该放在一起，如重载的函数

   垂直顺序

    自上而下展示函数调用依赖顺序

横向格式

  代码行上限应该是120个字符

  尽量不要拖动滚动条

  水平方向的区隔与靠近

   赋值操作符周围加上空格字符，达到强调的目的

   函数名和左括号不加空格，紧密相关

   括号中的参数一一隔开，强调逗号

  水平对其

   修饰符、参数类型，参数名起头在同一纵向上

团队规划

  格式规则团队说了算

  同一规则，借助IDE

最优代码格式

  成员变量声明应该紧紧挨着

  与构造器应该有一定间隔

  方法调用由上而下

  结构紧凑

  方法之间有间隔

  while for if 只有一句的时候，不要用 {}

第六章 对象和数据结构

数据抽象

  使用接口，不暴露细节，即使get set 方法，也可能暴露接口

  以最好的方式呈现某个对象包含的数据

数据对象的反对称型

  对象把数据隐藏于抽象

  数据结构暴露其数据

  过程式代码与面向对象代码

   过程式代码难以添加新数据结构，因为必须修改所有函数

   面向对象代码难以添加新函数，因为必须修改所有类

德墨忒尔定律

  模块不应了解它所操作对象的内部清醒

  隐藏内部结构

  类C 方法f只应该调用一下对象方法

   C

   f创建的对象

   作为参数传递给f的对象

   C的实体变量持有的对象

  隐藏结构 知道的尽量少

数据传送对象

DTO 数据传送对象

  只有公有变量，没有函数

第七章 错误处理

错误处理不能搞乱了逻辑代码

遇到错误的时候，最好抛出一个异常

try-catch-finally

  定义了一个范围

  try部分可随时取消，在catch语句接续

可控异常违反开闭原则

  抛出异常后必须修改调用者的方法签名 生命异常

  破坏封装

给出异常发生的环境说明

  失败操作

  失败类型

打包第三方API

  降低对他的依赖

  不用很痛苦的改代码库

  方便mock和模拟

  尽量封装自己的异常

不要返回null值

  返回特例对象

  可以返回空列表 Collections.emptyList()

不要传递null值

  除非API要求 否则尽量不传null值

第八章 边界

整洁的边界

  边界代码需要清洗分割和定义期望的测试

  避免过多了解第三方的特定信息

第九章 单元测试

编写测试，确保代码中每个犄角旮旯都如我所愿的工作

隔离 伪造

TDD三定律

  先写测试 后写代码

  1.在编写不能通过的单元测试前，不可写生产代码

  2.只可以编写刚好无法通过的单元测试，不能编译也算不通过

  只可以编写刚好足以通过当前失败测试的生产代码

测试代码和生产代码一样重要

保持测试整洁

没有单元测试，生产代码无法扩展，不敢修改

整洁的测试

  整洁测试三要素

   可读性

   可读性

   可读性

  明确、简洁，有足够的表达力

  测试的三个环节

   构造测试数据

   操作测试数据

   验证操作是否得到了期望的结果

  断言数量最小化

   尽量一个测试一个断言

  每个测试一个概念

整洁测试的五条规则 F.I.R.S.T

  快速 fast

   快速运行

  独立 independent

  可重复 repeatable

   任何环境下可重复通过

  自足验证 self-validating

   应该有布尔值输出

  及时 timely

   应该及时编写

代码整洁之道读书笔记

标签：apu   center   ssr   depend   tin   签名   打包   isp   好的   

原文地址：http://www.cnblogs.com/pengshuangbao/p/6275360.html