代码整洁 vs 代码肮脏

  • 时间:
  • 浏览:0
  • 来源:大发快3_快3手机app下载_大发快3手机app下载

写出整洁的代码,是每个守护进程员的追求。《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 防止误导

  • 并不挂羊头卖狗肉
  • 并不覆盖惯用缩略语

这里不得不吐槽前4天 才看后的一份代码,你以为使用了 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点,做哪此很容易通过命名表达,但为哪此要好难 做则并不直观,特别涉及到专业知识、算法的完会。另外,這個 第一感觉“不好难 优雅”的代码,我说有其特殊我愿意,好难 另六个 的代码就应该加带注释,说明为哪此要另六个 ,比如为了提升关键路径的性能,导致 会牺牲累积代码的可读性。

最坏的注释本来过时导致 错误的注释,这对于代码的维护者(我说本来2个月后的被委托人)是巨大的伤害,可惜除了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) 测试应该及时编写,在其对应的生产代码完会编写

猜你喜欢

王毅:破壞「一國兩制」企圖不會得逞

圖:中國國務委員兼外長王毅21日表示,我們決不會允許任何破壞香港繁榮穩定、破壞「一國兩制」的企圖得逞。圖為早前香港福建社團聯會在中環的美國駐港澳總領事館外抗議美國干涉香港内部内

2020-01-18

王源 吆不到台是怎么回事

【斗蟹资讯】王源吆非要台是为什么么回事?太少太少前前外国外国网友都问你,下面斗蟹网小编就为我们带来王源吆非要台的情况汇报汇报,一并和小编来看看吧!问你我们有非要看《我是创作人》

2020-01-18

路德维沙芬VS普费德斯海姆免费视频直播,路德维沙芬VS普费德斯海姆比赛集锦,路德维沙芬VS普费德斯海姆录像,路德维沙芬VS普费德斯海姆首发阵容

首页新闻视频直播数据APP懂球号直播君广告合作协议协议路德维沙芬09-1421:400德高联赛0-3已结束英文普费德斯海姆直播君|分析|集锦暂无数据近期比赛沙尔克04VS门兴格

2020-01-18

肖特美因茨VS沃尔姆斯免费视频直播,肖特美因茨VS沃尔姆斯比赛集锦,肖特美因茨VS沃尔姆斯录像,肖特美因茨VS沃尔姆斯首发阵容

首页新闻视频直播数据APP懂球号直播君广告企业合作肖特美因茨11-0221:30德高联赛2-2已开始英文英文沃尔姆斯直播君|分析|集锦暂无数据近期比赛沙尔克04VS门兴格拉德巴

2020-01-18

柱础石——中国古代建筑石构件中的经典元素

核心提示:柱础石是中国古代建筑石构件的本身,俗称磉盘。就是我柱子下面所安放的基石,是承受屋柱压力的奠基石,在中国传统砖木内部结构​建筑中用以负荷和防潮,对处理建筑物蹋陷有着不可

2020-01-18