幸运快3_快3app娱乐_幸运快3app娱乐

代码整洁 vs 代码肮脏

时间：2019-10-05 08:05:14 出处:幸运快3_快3app娱乐_幸运快3app娱乐

写出整洁的代码，是每个守护进程员的追求。《clean code》指出，要想写出好的代码，首先得知道类似是肮脏代码、类似是整洁代码；而且 通过几滴 的刻意练习，不能真正写出整洁的代码。

WTF/min是衡量代码质量的唯一标准，Uncle Bob在书中称糟糕的代码为沼泽（wading），这只突出了亲戚亲戚朋友是糟糕代码的受害者。国内有另三个白多更适合的词汇：屎山，真是都是很文雅而且 更加客观，守护进程员既是受害者也是加害者。

对于类似是整洁的代码，书中给出了大师们的总结：

  • Bjarne Stroustrup：优雅且高效；直截了当；减少依赖；只做好一件事
  • Grady booch：简单直接
  • Dave thomas：可读，可维护，单元测试
  • Ron Jeffries：不需要说重复、单一职责，表达力（Expressiveness）

其中，我最喜欢的是表达力（Expressiveness）类似描述，类似词似乎道出了好代码的真谛：用简单直接的辦法 描绘出代码的功能，太少所以我少。

本文记录阅读《clean code》但是自己“深有同感”机会“醍醐灌顶”的类似观点。

坦白的说，命名是一件困难的事情，要想出另三个白多恰到好处的命名还要一番功夫，尤其亲戚亲戚朋友的母语还都是编程语言所通用的英语。不过类似切都是值得了，好的命名我就的代码更直观，更有表达力。

好的命名应该有下面的特征：

1.1 名副真是

好的变量名告诉你：是类似东西，为类似占据 ，该为社 使用

机会还要通过注释来解释变量，那末就先得不那末名副真是了。

下面是书中的另三个白多示例代码，展示了命名对代码质量的提升

# bad code
def getItem(theList):
   ret = []
   for x in theList:
      if x[0] == 4:
         ret.append(x)
   return ret

# good code
def getFlaggedCell(gameBoard):
   '''扫雷游戏，flagged： 翻转'''
   flaggedCells = []
   for cell in gameBoard:
      if cell.IsFlagged():
         flaggedCells.append(cell)
   return flaggedCells

1.2 解决误导

  • 不需要说挂羊头卖狗肉
  • 不需要说覆盖惯用缩略语

这里不得不吐槽前两天才看多的一份代码，果然使用了 l 作为变量名；而且 ，user果然是另三个白多list（单复数都那末学！！）

1.3 有意义的区分

代码是写给机器执行，也是给人阅读的，所以概念一定要有区分度。

# bad
def copy(a_list, b_list):
    pass

# good
def copy(source, destination):
    pass

1.4 使用读的出来的单词

机会名称读沒有来，那末讨论的但是就会像个傻鸟

1.5 使用方便搜索的命名

名字长短应与其作用域大小相对应

1.6 解决思维映射

比如在代码中写另三个白多temp，那末读者就得每次看多类似单词的但是翻译成其真正的意义

有表达力的代码是不需要注释的：The proper use of comments is to compensate for our failure to express ourself in code.

注释的适当作用在于弥补亲戚亲戚朋友用代码表达意图时遇到的失败，这听起来我就懊恼，但事实真是那末。The truth is in the code, 注释所以我二手信息，二者的不同步机会不等价是注释的最大问題。

书中给出了另三个白多非常形象的例子来展示：用代码来阐述，而非注释

bad
// check to see if the employee is eligible for full benefit
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

good
if (employee.isEligibleForFullBenefits())

而且 ，当不需要加上注释的但是，都还要想想否是是都还要通过修改命名，机会修改函数（代码）的抽象层级来展示代码的意图。

当然，所以我就因噎废食，书中指出了以下类似状态属于好的注释

  • 法务信息
  • 对意图的注释，为类似要那末做
  • 警示
  • TODO注释
  • 放大看似不合理之物的重要性

其中自己最赞同的是第2点和第5点，做类似很容易通过命名表达，但为类似要那末做则不需要说直观，特别涉及到专业知识、算法的但是。另外，类似第一感觉“不那末优雅”的代码，你爱不爱我有其特殊不需要，那末从前的代码就应该加上注释，说明为类似要从前，比如为了提升关键路径的性能，机会会牺牲要素代码的可读性。

最坏的注释所以我过时机会错误的注释，这对于代码的维护者（你爱不爱我所以我有几个月后的自己）是巨大的伤害，可惜除了code review，并那末简单易行的辦法 来保证代码与注释的同步。

3.1 函数的单一职责

另三个白多函数应该只做一件事，这件事应该能通过函数名就能清晰的展示。判断辦法 很简单：看看函数否是是还能再拆出另三个白多函数。

函数要么做类似do_sth, 要么查询类似query_sth。最恶心的所以我函数名表示只会query_sth, 但事实上却会do_sth, 这使得函数产生了副作用。比如书中的例子

public class UserValidator {
    private Cryptographer cryptographer;
    public boolean checkPassword(String userName, String password) {
        User user = UserGateway.findByName(userName);
        if (user != User.NULL) {
            String codedPhrase = user.getPhraseEncodedByPassword();
            String phrase = cryptographer.decrypt(codedPhrase, password);
            if ("Valid Password".equals(phrase)) {
                Session.initialize();
                return true;
            }
        }
        return false;
    }
}

3.2 函数的抽象层级

每个函数另三个白多抽象层次，函数中的句子都是在同另三个白多抽象层级，不同的抽象层级不能倒进一并。比如亲戚亲戚朋友想把大象倒进冰箱，应该是类似样子的：

def pushElephantIntoRefrige():
    openRefrige()
    pushElephant()
    closeRefrige()

函数里边的三句代码在同另三个白多层级（层厚）描述了要完成把大象倒进冰箱这件事顺序相关的另三个白多步骤。显然，pushElephant类似步骤又机会涵盖所以子步骤，而且 在pushElephantIntoRefrige类似层级，是不需要知道太少细节的。

当亲戚亲戚朋友想通过阅读代码的辦法 来了解另三个白多新的项目时，一般都是采取广度优先的策略，自上而下的阅读代码，先了解整体特征，而且 再深入感兴趣的细节。机会那末对实现细节进行良好的抽象（并凝练出另三个白多名副真是的函数），那末阅读者就容易迷失在细节的汪洋里。

类似程度看来，类似跟金字塔原理也很像

每另三个白多层级都是为了论证其上一层级的观点，一并也还要下一层级的支持；同一层级之间的多个论点又还要以类似逻辑关系排序。pushElephantIntoRefrige所以我中心论点，还要多个子步骤的支持，一并类似子步骤之间都是逻辑先后顺序。

3.3 函数参数

函数的参数太少，组合出的输入状态就愈多，还要的测试用例也就太少，也就越容易出问題。

输出参数相比返回值难以理解，这点深有同感，输出参数真是是很不直观。从函数调用者的层厚，一眼就能看出返回值，而那末识别输出参数。输出参数通常逼迫调用者去检查函数签名，类似真是不友好。

向函数传入Boolean（书中称之为 Flag Argument）通常都是好主意。尤其是传入True or False后的行为并都是一件事情的两面，所以我两件不同的事情时。这很明显违背了函数的单一职责约束，解决辦法 很简单，那所以我用另三个白多函数。

3.4 Dont repear yourself

在函数类似层级，是最容易、最直观实现复用的，所以IDE也难帮助亲戚亲戚朋友讲一段代码重构出另三个白多函数。

不过在实践中，也会总出 从前类似状态：一段代码在多个辦法 中都是使用，而且 又不完全一样，机会抽象成另三个白多通用函数，那末就还要加参数、加if else区别。从前都特别尴尬，貌似都还要重构，但又都是很完美。

造成上述问題的类似状态是机会，这段代码也违背了单一职责原则，做了不只一件事情，这才原因分析分析分析不好复用，解决辦法 是进行辦法 的细分，不能更好复用。也都还要考虑template method来解决差异的要素。

非常惭愧的是，在我经历的项目中，测试（尤其是单元测试）时不时都那末得到足够的重视，也那末试行过TDD。正机会缺失，才更感良好测试的珍贵。

亲戚亲戚朋友常说，好的代码还要有可读性、可维护性、可扩展性，好的代码、架构还要不停的重构、迭代，但自动化测试是保证类似切的基础，那末高覆盖率的、自动化的单元测试、回归测试，谁都是敢去修改代码，不能任其腐烂。

即使针对核心模块写了单元测试，一般也很随意，认为这所以我测试代码，配不上生产代码的地位，以为而且我能跑通就行了。这就原因分析分析分析测试代码的可读性、可维护性非常差，而且 原因分析分析分析测试代码那末跟随生产代码一并更新、演化，最后原因分析分析分析测试代码失效。所以说，脏测试 - 等同于 - 没测试。

而且 ，测试代码的三要素：可读性，可读性，可读性。

对于测试的原则、准则如下：

  • You are not allowed to write any production code unless it is to make a failing unit test pass. 那末测试但是不需要说写任何功能代码
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 只编写恰好不能体现另三个白多失败状态的测试代码
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 只编写恰好能通过测试的功能代码

测试的FIRST准则：

  • 快速（Fast）测试应该够快，尽量自动化。
  • 独立（Independent） 测试应该应该独立。不需要说相互依赖
  • 可重复（Repeatable） 测试应该在任何环境上都能重复通过。
  • 自我验证（Self-Validating） 测试应该有bool输出。不需要说通过查看日志类似低速率单位辦法 来判断测试否是是通过
  • 及时（Timely） 测试应该及时编写，在其对应的生产代码但是编写

热门

热门标签