• 注释:

    • 不恰当的信息:注释只应该描述有关代码和设计的技术性信息。
    • 废弃的注释:过时、无关或不正确的注释就是废弃的注释。
    • 冗余注释:注释应该谈及代码自身没提到的东西
    • 糟糕的注释:值得编写的注释,也值得好好写。
    • 注释掉的代码
  • 环境:
    • 需要多步才能实现的构建:构建系统应该是单步的小操作。
    • 需要多步才能做到的测试:应当能够发出单个指令就可以运行全部单元测试。能够运行全部测试是如此基础和重要,应该快速、轻易和直截了当地做到。
  • 函数
    • 过多的参数,没参最好
    • 输出参数:输出参数就违反直觉。如果函数非要修改什么东西的状态不可,就修改它所在对象的状态好了。
    • 标识参数:布尔值参数大声宣告函数做了不止一件事。
    • 死函数:永不被调用的方法应该丢弃。别害怕删除函数。
  • 一般性问题:
    • 一个源文件中存在多种语言:理想的源文件包括且只包括一种语言,应该尽力减少源文件中额外语言的数量和范围。
    • 明显的行为未被实现:最小惊异原则--函数或类应该实现其他程序员有理由期待的行为。
    • 不正确的边界行为:别依赖直觉。追索每种边界条件,并编写测试。
    • 忽视安全:关闭失败测试、告诉自己过后再处理,这和假装刷信用卡不用还钱一样坏。
    • 重复:核心原则。每次看到重复代码,都代表遗漏了抽象。
    • 在错误的抽象层级上的代码:只与细节实现有关的常量、变量或工具函数不应该在基类中出现。
    • 基类依赖于派生类:例外情况是派生类数量严格固定。
    • 信息过多:设计良好的模块有着非常小的接口,让你能事半功倍。设计良好的接口并不提供许多需要依靠的函数,所以耦合度也较低。设计低劣的接口提供大量你必须调用的的函数,耦合度较高。隐藏你的数据。隐藏你的工具函数。隐藏你的常量和你的临时变量。不要创建拥有大量方法或大量实体变量的类。不要为子类创建大量受保护变量和函数。尽量保持接口紧凑。通过限制信息来控制耦合度。
    • 死代码:死代码就是不执行的代码。
    • 垂直分隔:变量和函数应该在靠近被使用的地方定义。
    • 前后不一致:从一而终,小心选择约定,一旦选中,就小心持续遵循。
    • 混淆视听:
    • 人为耦合:不互相依赖的东西不该耦合。
    • 特性依恋:类的方法只应对其所属类中的变量和函数感兴趣,不该垂青其他类中的变量和函数。
    • “选择算子”参数:“选择算子”参数只是一种避免把大函数切分为多个小函数的偷懒做法。选择算子不一定是boolean类型,可能是枚举元素、整数或任何一种用于选择函数行为的参数。
    • 晦涩的意图:代码要尽可能具有表达力。
    • 位置错误的权责:软件开发者做出的最重要决定之一就是在哪里放代码。(最小惊异原则)代码应该放在读者自然而然期待它所在的地方。
    • 不恰当的静态方法:恰当的静态方法不应在单个实体上操作。
    • 应当使用解释性变量:让程序可读的最有力的方法之一就是将计算过程打散成在用有意义的单词命名的变量中放置的中间值。
    • 函数名称应该表达其行为:
    • 理解算法:“可以工作”是不行的,必须知道解决方案是正确的。
    • 应当把逻辑依赖改为物理依赖:依赖者模块不应对被依赖者模块有假定。
    • 应当用多态替代if/else或switch/case: 在使用if/else或switch/case前,先考虑使用多态。
    • 遵循标准约定:
    • 用命名常量替代魔术数:
    • 准确:
    • 结构甚于约定:坚守结构甚于约定的设计决策。命名约定很好,但却次于强制性的结构。
    • 封装条件:应该把解释了条件意图的函数抽离出来。
    • 避免否定性条件:
    • 函数只做一件事:
    • 不要掩蔽时序耦合:通过创建时序队列暴露时序耦合。
    • 应当封装边界条件:
    • 函数应当只在一个抽象层级上:(拆分不同抽象层级是重构的最重要的功能之一)
    • 应当在较高层级放置可配置数据
    • 避免传递浏览:确保模块只了解其直接协作者。
  • Java
    • 通过使用通配符避免过长的导入清单:(这一项由IDE来实现)
    • 不要继承常量:
    • 常量 VS. 枚举 :优先用枚举
    • 采用描述性名称:
    • 名称应与抽象层级相符
    • 尽可能使用标准命名法:
    • 无歧义的名称:
    • 避免编码:不应在名称中包括类型或作用范围信息。
    • 名称应该说明副作用:名称应该说明函数、变量或类的一切信息。
  • 测试:
    • 测试不足:
    • 使用覆盖率工具:覆盖率工具能汇报你测试策略中的缺口。
    • 别略过小测试
    • 被忽略的测试就是对不确定事物的疑问:需求不明确而不能确定某个行为细节,可以用注释掉的测试或者用@Ignore标记的测试来表达我们对于需求的疑问。
    • 测试边界条件
    • 全面测试相近的缺陷
    • 测试失败的模式有启发性
    • 测试覆盖率的模式有启发性
    • 测试应该快速

Clean Code 代码检查清单的更多相关文章

  1. 读《Clean Code 代码整洁之道》之感悟

    盲目自信,自认为已经敲了几年代码,还看什么整洁之道啊.我那可爱的书架读懂了我的心思,很明事理的保护起来这本小可爱,未曾让它与我牵手 最近项目中的 bug 有点多,改动代码十分吃力,每看一行代码都带一句 ...

  2. Clean Code 代码整洁之道

    军规:让营地比你来时更干净. 整洁代码 Leblanc : Later equals never. (勒布朗法则:稍后等于永不) 对代码的每次修改都影响到其他两三处代码. 修改无小事. 如同医生不能遵 ...

  3. OC静态代码检查实战

    此文已由作者杨晓授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 在Mac OS系统上,采用Xcodebuild Analyze命令和OClint工具,对iOS项目进行静态代码 ...

  4. 《Clean Code》 代码简洁之道

    作者介绍 原文作者: Robert C. Martin, Object Mentor公司总裁,面向对象设计.模式.UML.敏捷方法学和极限编程领域的资深顾问,是<敏捷软件开发:原则.模式.与实践 ...

  5. 《代码整洁之道》(Clean Code)- 读书笔记

    一.关于Bob大叔的Clean Code <代码整洁之道>主要讲述了一系列行之有效的整洁代码操作实践.软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关.这一点,无论是敏捷开发流派 ...

  6. Clean Code之JavaScript代码示例

    译者按: 简洁的代码可以避免写出过多的BUG. 原文: JavaScript Clean Code - Best Practices 译者: Fundebug 本文采用意译,版权归原作者所有 引文 作 ...

  7. 代码整洁之道Clean Code笔记

    @ 目录 第 1 章 Clean Code 整洁代码(3星) ?为什么要整洁的代码 ?什么叫做整洁代码 第 2 章 Meaningful Names 有意义的命名(3星) 第 3 章 Function ...

  8. 《clean code》讲述代码中的道,而不是术

    Clean code 看<clean code>一书,学习高手写出的代码,简单高效的代 1.目标 Bjarne Stroustrup:优雅且高效:直截了当:减少依赖:只做好一件事 Grad ...

  9. 程序员必备的代码审查(Code Review)清单【转载】

    在我们关于高效代码审查的博文中,我们建议使用一个检查清单.在代码审查中,检查清单是一个非常好的工具——它们保证了审查可以在你的团队中始终如一的进行.它们也是一种保证常见问题能够被发现并被解决的便利方式 ...

随机推荐

  1. C函数指针数组的定义和使用

    1.使用函数指针数组来实现计算器 2.通过函数指针变量来调用对应的函数 #include <stdio.h> int add(int a,int b){ return a+b; } int ...

  2. 红黑树 ------ luogu P3369 【模板】普通平衡树(Treap/SBT)

    二次联通门 : luogu P3369 [模板]普通平衡树(Treap/SBT) 近几天闲来无事...就把各种平衡树都写了一下... 下面是红黑树(Red Black Tree) 喜闻乐见拿到了luo ...

  3. fhq treap ------ luogu P3369 【模板】普通平衡树(Treap/SBT)

    二次联通门 : LibreOJ #104. 普通平衡树 #include <cstdio> #include <iostream> #include <algorithm ...

  4. Day13:H5+JS+C3

    css布局中,什么是BFC BFC是Block formatting context的缩写,表示"块级格式化上下文". 设置BFC的元素,是一个独立的渲染区域,只有Block-le ...

  5. HDU-盐水的故事

    http://acm.hdu.edu.cn/showproblem.php?pid=1408 这是一道高精度问题: 在自己错了数十遍之后找到了不少规律: 首先是Output limit exceede ...

  6. laravel 多控制器路由

    laravel 路由: ======================================= 公司的情况很不乐观...... 破产清算随时可能发生......

  7. JS 星号 * 处理手机号和名称

    有时候为了不让用户看到手机号和姓名,需要针对手机号和姓名进行 * 处理. 比如: 13140121671  =>  "131****1671" '王宝宝'  =>  & ...

  8. 小程序在选择某一个东西的时候,可以用if,else 来做

    <view class='fake-select-item-text brand-selected' wx:if='{{selectedBrandName}}'> {{selectedBr ...

  9. struts的带参数结果集

    action在forward过程中共享一个值栈,也就是一次request只有一个值栈,服务器端的forward对于客户端来说就是一次request,在forward过程就没必要再传参数了. 总结也就是 ...

  10. LCT 总结

    刚开始学lct花了一晚上研究模板,调出来就感觉不怎么难打了. 对板子的浅显理解: lct维护树形联通块,通过splay维护实链,可以把需要的路径变换到一颗splay上维护. splay中的关系只依赖实 ...