大发pk10_pk10破解_大发pk10破解 - 大发pk10,pk10破解,大发pk10破解为网友提供全面快捷权威的综合大发pk10,pk10破解,大发pk10破解信息报道,包括新闻、国内国际要闻、体育娱乐新闻、社会生活新闻、博览会新闻、房产、汽车、健康女性、IT等多类服务

代码整洁 vs 代码肮脏

  • 时间:
  • 浏览:1

写出整洁的代码,是每个程序员的追求。《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()

函数顶端的三句代码在同有十个 多多层级(深度1)描述了要完成把大象倒进冰箱这件事顺序相关的有十个 多多步骤。显然,pushElephant你这名步骤又可能性所含也不 子步骤,假如有一天在pushElephantIntoRefrige你这名层级,是我越多 知道越多细节的。

我们我们我们我们 想通过阅读代码的最好的妙招来了解有十个 多多新的项目时,一般有的是采取广度优先的策略,自上而下的阅读代码,先了解整体价值形式,假如有一天再深入感兴趣的细节。可能性没人对实现细节进行良好的抽象(并凝练出有十个 多多名副我觉得的函数),没人阅读者就容易迷失在细节的汪洋里。

有这名程度看来,你这名跟金字塔原理也很像

每有十个 多多层级有的是为了论证其上一层级的观点,一同也须要下一层级的支持;同一层级之间的多个论点又须要以有这名逻辑关系排序。pushElephantIntoRefrige也不 中心论点,须要多个子步骤的支持,一同哪些子步骤之间有的是逻辑先后顺序。

3.3 函数参数

函数的参数越多,组合出的输入情况就愈多,须要的测试用例也就越多,也就越容易出问题报告 。

输出参数相比返回值难以理解,这点深有同感,输出参数我觉得是很不直观。从函数调用者的深度1,一眼就能看出返回值,而没能识别输出参数。输出参数通常逼迫调用者去检查函数签名,你这名我觉得不友好。

向函数传入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) 测试应该及时编写,在其对应的生产代码完后 编写