代码编写时,我们通常要考虑架构,测试,效率等因素。在这些因素之外,代码可读性是一种很重要的原则。不管是今后代码的复用,维护,还是学习,构建可读性好的代码无疑是正确的。我们编写代码时,通常会按直觉或者灵感,也会按直白和紧凑来写。那么这些定法到底是好不好呢。有没有一个对这些写法的度量标准呢。
代码的写法应该使理解的时间最小化,这个理解不光是别人,也是几个月后的自己。自己写的代码在很长时间内,都是自己来维护的。在进行关于这个度量问题的讨论时,先看几段代码:
代码段一:
for(Node *node = list-head; node != NULL; node = node->next)
print(node->data);
代码段二:
Node* node = list->head;
if(node == NULL) return;
while(node->next != NULL){
print(node->data);
node = node -> next;
}
if(node != NULL) print(node->data);
代码段一与代码段二行为上相同,但是二显得杂乱,理解时间可能更长,而段一更加直白。
再来看一下一个更加紧凑的代码:
return exponent >=0?mantissa*(1<<exponet):mantissa/(1<<-exponent);
上面代码紧凑,但是层次复杂,对语法要求高,不适合大众理解。如果改写成下面的样子:
if(exponet >=0)
{
return mantissa*(1<<exponet);
}
else
{
return mantissa/(1<<-exponent);
}
上面的例子说明,写代码不是要使代码紧凑,也不随想随写,也不是写更少的代码,而是要写容易理解的代码。
我们可以通过分解嵌套等级降低理解难度:
assert((!(bucket = FindBucket(key)))||!bucket->IsOccupied());
如果分解成:
bucket = FindBucket(key);
if(bucket != NULL)
assert(!bucket->IsOccupied());
这样改写可以降低人的理解时间。
加一条注释也可以起到效果,这对理解公式运算方面有很大帮助。
//fast version of "hash =(65599*hash)+c“
hash = (hash <<6)+(hash<<16) -hash +c;
上面的语句采用位移代替乘法运算,是一条效率高的代码,但是也降低了可理解性,增加了理解时间。加一条注释,则可以明白表达算法,无需再逐条推导。
请记住这条度量定理:代码的写法应该使理解时间最小化。