• 代码整洁之道


    第一章 整洁代码

    赶上期限的唯一方法:始终尽可能保持代码整洁。

    整洁的代码只做好一件事。

    整本书的主旨,不要重复代码,只做一件事,表达力,小规模抽象。

    要想干得快,要想快点做完,要想轻松写代码,先让代码易读吧。

    让每次签入时,代码都比签出时干净。

    第二章,有意义的命名

    1、名副其实

    如果名称需要注释来补充,那就不算是名副其实。

    2、避免误导

    别用xxxList来指称一组账号,除非它真的是List类型。(用xxxGroup/bunchOfxxx/xxxs代替更好)

    3、做有意义的区分

    不要使用数字区分变量/函数命名。如a1,a2,…

    不要添加废话区分命名。如:ProductInfo和ProductData

    4、使用读得出来的名称

    比如日期:用generationTimestamp,而不要使用genymdhms。

    5、使用可搜索的名称

    单字母和数字常量很难搜出。使用宏或者变量命名这类数据。

    6、避免使用编码

    不必用前缀表示成员变量。

    7、避免思维映射

    8、类名

    类名和对象应该是名词或名词短语。

    9、方法名

    方法名应该是动词或动词短语。

    10、别扮可爱

    11、每个概念对应一个词

    12、别用双关语

    避免将同一个单词用于不同目的。

    13、使用解决方案领域名称

    尽可能使用IT类术语

    14、使用源自所涉问题领域的名称

    15、使用有意义的语境

    如:使用addrState代替state

    16、不要添加没用的语境

    如:不要用GSD代替GasStationDeluxe这样类似的短语。

    第三章 函数

    函数的第一规则是要短小,第二规则是还要更短小。

    函数的缩进层数不该多于一层或两层。

    函数应该做一件事,做好这件事,只做这一件事。

    要判断函数是否不止做了一件事,看是否能再拆出一个函数,该函数不仅是单纯地重新诠释其实现。

    函数参数,最理想的参数是0,其次是1,再次是2.尽量避免3个。有足够特殊的理由才能用3个以上函数。

    如果函数看起来需要两个,三个或三个以上参数,就说明其中一些参数应该封装成类了。

    函数不应有副作用,如,检查密码的函数不应该有初始化Session的步骤。

    把指令和询问分隔开来。

    别重复自己。

    如何做到:先想些什么就写什么,然后再打磨它。

    第四章 注释

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

    注释会撒谎,因为修改代码后并不会让注释随之变动。

    注释不会美化糟糕的代码。

    与其花时间美化代码,不如花时间清洁代码。

    好注释:

    1、法律信息

    2、提供信息的注释

    3、对意图的注释

    4、阐释

    5、警示

    6、TODO

    7、放大:放大某种看起来不合理之物的重要性

    8、公共API中的javadoc

    坏注释:

    1、喃喃自语

    2、多余的注释

    3、误导性注释

    4、循规式注释

    5、日志式注释

    6、废话注释

    7、可怕的废话

    8、能用函数或变量时就别用注释

    9、位置标记

    10、括号后面的注释

    11、归属和署名

    12、注释掉的代码(别这么干)

    13、html注释

    14、非本地信息

    15、信息过多

    16、不明显的联系

    17、函数头

    18、非公共代码中的javadoc

    第五章 格式

    代码格式很重要,关乎沟通。

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

    相关函数。若某个函数调用了另一个,就应该把它们放到一起。而且调用着应该尽可能放在被调用着上面。

    四则运算时,运算级较高的符号可以不用空格隔开。

    每个程序员都有自己喜欢的格式规则,但如果在一个团队中工作,就是团队说了算。

    第六章 对象和数据结构

    隐藏实现并非只是变量之间放上一个函数层那么简单。隐藏实现关乎抽象。类并不简单地用取值器和赋值器将变量推向外间,而是暴露抽象接口,以便用户无需了解数据的实现便能操作数据本体。

    要以最好的方式呈现某个对象包含的数据,需要做严肃的思考。

    过程式代码便于在不改动既有函数的前提下添加新类。

    得墨耳律:模块不应了解它所操作对象的内部情形。

    例如:类C的f方法只应调用以下对象的方法:

    C 由f创建的对象

    由C的实体变量持有的对象

    即:方法不应调用由任何函数返回的对象的方法。

    第七章 错误处理

    使用异常而非返回码。 先写try、catch、finally语句

    使用不可控异常

    给出异常发生的环境说明。 > 应创建信息充分的错误信息,并和异常一起传递出去。在消息中,包括失败的操作和失败的类型。如果你的应用程序由日志系统,传递足够的信息给catch块,并记录下来。

    依调用者需要定义异常类。

    定义常规流程。

    别返回null值。

    别传递null值。

    第九章 单元测试

    TDD三定律

    1、在编写不能通过的单元测试前,不可编写生产代码。

    2、只可编写刚好无法通过的单元测试,不能编译也不算通过。

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

    保持测试整洁。

    脏测试等同于没测试。

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

    整洁的测试三要素:可读性,可读性和可读性。

    每个测试一个断言。

    每个测试只测试一个概念。

    F.I.R.S.T.

    Fast(快速)、Independent(独立)、Repeatable(可重复)、Self-Validating(自足验证)、Timely(及时)

    第十章 类

    类应该短小。

    用权责衡量类的大小。

    如果无法为某个类命以精确的名称,这个类大概太长了。

    SRP,单一权责原则,类或模块应有且只有一条加以修改的理由。

    系统应该有许多短小的类而不是少量巨大的类组成。每个小雷封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为。

    内聚:如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性。

    第十一章 系统

    将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中,设计系统的其他部分时,假设所有对象都已正确构造和设置。

    使用工厂方法,让程序负责确定何时创建对象。

    AOP 切面编程

    第十二章 迭进

    简单设计四条规则:

    运行所有测试;

    不可重复;

    表达了程序员的意图;

    尽可能减少类和方法的数量。

    极其雷同的代码就是重复。

    要想实现大规模复用,必须理解如何实现小规模复用。

    模板方法模式是一种移除高层级重复的通用技巧

    第十三章 并发编程

    对象是过程的抽象,线程是调度的抽象。

    并发是一种解耦策略,帮助我们把做什么(目的)和何时(时间)做分解开。

    并发会在性能和编写额外代码上增加一些开销。

    正确的并发是复杂的,即便对于简单的问题也是如此。

    并发缺陷并非总能重现,所以常被看做偶发事件而忽略,未被当作真的缺陷对待。

    并发常常需要对设计策略的根本性修改。

    并发防御原则:

    1、SRP,分离并发相关代码和其他代码。

    2、推论:限制数据作用域。

    3、推论:使用数据复本,避免共享数据的好方法之一就是一开始就避免共享数据。

    4、推论:线程应尽可能独立。尝试将数据分解到可独立线程(可能在不同处理器上)操作的独立子集。

    并发执行模型

    生产者-消费者

    读者-作者

    宴席哲学家

    学习这些基础算法,理解其解决方案。

    在你认为自己完成某个函数之前,确认自己理解了它是怎么工作的。通过全部测试还不够好。你必须知道解决方案是正确的。获得这种知识和理解的最好途径,往往是重构函数,得到某种整洁而足具表达力、清楚呈示如何工作的东西。

    用多态替代If/Else或Switch/Case

    总结

    看了这本书,得到了很多新的指导,建议。这确实是一本好书,作者表达很清晰,说明白了该怎么做。虽然知道了,但是还是得要根据当中的理论多去实践才能体会当中的精髓。

    原文:

    http://www.hoohack.me/2016/03/23/code-clean-read-note

  • 相关阅读:
    数据库 第一、二、三范式
    JVM垃圾回收(GC)整理总结学习
    ConcurrentHashMap
    Java GC、新生代、老年代
    Android -- 查看手机中所有进程
    ThreadLocal
    Android -- DrawerLayout
    WeakReference与SoftReference
    ASP.NET Core Web服务器 Kestrel和Http.sys 特性详解
    微服务架构体系
  • 原文地址:https://www.cnblogs.com/chunguang/p/5538161.html
走看看 - 开发者的网上家园