CleanCode-注释和格式

注释

注释的恰当用法是弥补在用代码表达意图时遭遇的失败。

注释会撒谎,注释存在的时间越久,离描述的代码越远,因为成员不能坚持维护注释。
把力气用在写清楚代码上,直接保证无需编写注释。
不准确的注释要比没注释坏的多,真实只在代码中体现,虽然需要注释,但是应该花心思尽量减少注释。

1.注释不能美化糟糕的代码

带有少量注释的整洁而有表达力的代码更好。

2.用代码来阐述

//check to see if the employee is eligible for full benefits
if((employee.flags & HOURLY_FLAG) && emplyee.age > 65) {
    
}

还是

if(employee.isEligibleForFullBenefits()) {
    
}

3.好注释

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

(1)法律信息
(2)提供信息的注释

//Returns an instance of the Responder being tested
protected abstract Responder responderInstance();

更好的方式是尽量利用函数名称传达信息,这样注释就是多余了。

protected abstract ResponderBeingTested responderInstance();

再比如,

//format matched kk:mm:ss EEE,MMM dd, yyyy
Pattern timeMatcher = Pattern.compile("\\d*:\\d*:\\d* \\ w*, \\w* \\d*, \\d*)

该正则表达式意在匹配一个经由SimpleDateFormat.format函数利用特定格式字符串格式化的时间和日期。

可以将这段代码转移到某个转换日期和时间格式的类中,会更好、更清晰。

(3)对意图的解释

你也许不同意程序员给这个问题提供的解决方案,但至少知道它要干什么。

(4)阐释

注释把某些晦涩难明的参数或返回值的意义翻译为某种可读形式。适合单行之后//

(5)警示

警告其他程序员会出现某种后果,解释为什么要关闭某个测试用例。
可以结合注释 @Ignore("Takes too long to run")

public static SimpleDateFormat makeStandardHttpDateFormat() {
	// SimpleDateFormat is not thread safe
    // so we need to create each isntance independently;
    SimpleDateFormat df = new SimpleDateFormat("EEE," dd MMM yyyy HH:mm:ss z);
	df.setTimeZone(TimeZone.getTimeZone("GMT"));
	return df;
}

虽然可能有更好的解决方法,不过上面的注释有道理存在,能阻止某位程序员以效率之名使用静态初始器。

(6)TODO注释
解释为什么该函数的实现部分无所作为,将来应该是如何。
认为应该做,但由于某些原因目前还没做。

(7)放大

注释用来重点描述看起来不合理之物的重要性

String listItemcount = match.group(3).trim();
// the trim is real important.It removes the starting spaces that cause the item to be recognized as anoter list

(8)公共API中的Javadoc

良好描述的公共API,标准java库中的Javadoc一般不错。

4.坏注释

有的注释可以省去读者读具体算法的精力,可以留下。

(1)喃喃自语、废话连篇

(2)多余的注释,简单函数的头部位置注释

(3)误导性注释

(4)循规式注释,不要为了写注释而写注释,不用每个函数都写。

(5)日志式注释

在每次编辑代码时,在模块开始处添加一条注释,这类注释就像是一种记录每次修改的日志。

(6)能用函数或变量就别用注释,短函数不需要太多描述,为制作一件事的短函数选个好名字,通常要比函数头注释更好。

(7)不要在括号后面写注释

(8)归属与署名,源代码控制系统是最好的归属地。没必要为小小的签名搞脏代码

(9)注释掉的代码,要么就删除,要么就不要留。

(10)HTML注释

格式

代码的可读性会对以后发生的修改行为产生深远影响。
大多数代码为200行,最长500行。

1.垂直格式

几乎所有的代码都是从上往下读,从左往右读。

间隔

每行展现一个表达式或一个子句,每组代码行展示一条完整的思路。这些思路用空白行区隔开来。

靠近

靠近的代码暗示紧密联系,实体变量有联系则互相靠近。

顺序

被调用的函数应该放在执行函数下面。

2.横向格式

代码行尽量短小,80个字符以内,上限120个字符。

间隔和靠近

空格字符,逗号,进行分隔,空格字符也可以强调前面的运算符。

对齐

用不对齐的声明和赋值,能够指出重点。
如果有较长的列表需要对齐处理,问题在列表的长度上,而不是对齐上。

缩进

洞悉变量、构造器和方法等。
尽量不要违反缩进规则,即使在短小的if、while和小函数中。

3.团队规则

在团队,团队说了算

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值