[学习笔记] 《代码整洁之道》(三)

[学习笔记] 《代码整洁之道》—第4章 注释

  • 什么也比不上放置良好的注释来的有用!

  • 什么么也比不上乱七八糟的注释更有本事捣乱一个模块!

  • 什么也不会比陈旧、提供错误信息的注释更有破坏性!

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

    • 注释总是一种失败;
    • 注释会撒谎:主食存在的时间越久,就离所描述的代码越远,越来越变得全然错误。
  • 程序员应当负责将注释保持在可维护有关联、和精确的高度。

    • 不准确的注释要比没有注释还糟糕。
  • 唯一真实的就是代码

    • 尽管有时需要注释,我们也该多花心思尽量减少注释。

注释不能美化糟糕的代码

  • 写注释的常见动机之一就是糟糕的代码的存在。
    • 带有少量注释的整洁而又表达力的代码,要比带有大量注释的零碎而复杂的代码像样得多。
    • 与其花时间编写解释糟糕代码的注释,不如花时间清洁那堆糟糕的代码。

用代码来阐述

  • 有时,代码本身不足以解释其行为

    • 有的程序员认为:代码很少 —> 如果有的话 —> 能做好解释工作 (错误!!!)

      // Check to see if the employee is eligible for full benefits
      if((employee.flags & HOURLY_FLAG) &&
         (employee.age >65))
      
      // 或许你更愿意看到这个
      if(employee.isEligibalForFullBenefits())
      
  • 只要多花一点时间,就能用代码解释你大部分意图。

好注释

有些注释是必须的,也是有利的。

唯一真正好的注释就是想办法不去写的注释。

  • 法律信息 :版权及著作权声明

    // Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
    // Released under the terms of the GUN General Public License version 2 or later.
    
    • 这类注释不应该是合同或法典。
    • 只要有可能,就只想一份标准许可或其他外部文档,而不是把所有条款放到注释中。
  • 提供基本信息

    • 这类注释有时管用,但更好的方式是尽量用函数名称传达信息。
  • 不仅提供了有关实现的有用信息,还提供了某个决定后面的意图。

  • 把某些晦涩难明的参数或者返回值的意义翻译为某种可读形式。

    • 更好的方式是尽量让参数或返回值滋生足够清楚。
    • 如果参数或返回值是某个标准库的一部分,或是你不能修改代码,帮助阐述其含义的代码就会有用。
  • 警告其他程序许愿出现某种后果

  • 用//TODO 形式在源代码中放置要做的工作列表。

  • 放大某种开来不合理之物的重要性。

  • 没有比被良好描述的公共API更有用和令人满意的了。

坏注释

坏注释都是糟糕的代码的支撑借口,或者对错误决策修正,基本上等于程序员的自说自话

  • 如果只是因为你觉得应该或者过程需要就添加注释,那就是无谓之举。

    • 如果你决定写注释,就要花必要的时间确保写出最好的注释。
  • 多余的注释

    • 不能比代码本身提供更多的信息
    • 没有证明代码的意义
    • 没有给出代码的意图或逻辑
  • 误导性注释

  • 循规式注释

  • 日志式注释

  • 废话注释

  • 可怕的废话

    /** The name **/
    private String name;
    
    /** The version **/
    private String version;
    
  • 能用函数或者变量时就别用注释

    // does the module from the global list <mod> depend on the
    // subsystem we are part of?
    if(smodule.getDependSubsystems().contains(subSysMod.getSubSystem()))
    

    改成没有注释的版本如下

    ArrayList moduleDependees = smodule.getDependSubsystems();
    String ourSubSystem = subSysMod.getSubSystem();
    if(moduleDependees.contains(ourSubSystem))
    
  • 位置标记

  • 括号后面的注释

    try{
        /* ... */
        /* ... */
        while(1){
            /* ... */
            /* ... */
            /* ... */
        } //while
        /* ... */
        /* ... */
    } //try
    catch{
        /* ... */
    } //catch
    
    • 如果你发现自己想标记有括号,其实应该做的是缩短函数
  • 归属和署名

    /* Added by Rick */

  • 注释掉的代码

    • 直接把代码注释掉是讨厌的作法,别这么干!
  • HTML注释

  • 非本地信息

    • 如果你一定要写注释,请确保它描述了离它最近的代码。
    • 别在本地注释的上下文环境中给出系统级的信息。
  • 信息过多

    • 别在注释中添加有趣的历史性话题或者无关的细节描述。
  • 不明显的联系

    • 注释和其描述的代码之间的联系应该显而易见。
  • 函数头

    • 短函数不需要太多的描述。
    • 为只做一件事的短函数选个好名字,通常比写函数头注释要好!

参考文献

[1] Robert C. Martin 著,韩磊 译,《代码整洁之道》,北京:人民邮电出版社,2010.1(2018.9 重印), ISBN 978-7-115-21687-8。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值