文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

本博文是对Let’s Stop Copying C的快速回复。

作为开场白,我同意Eevee的绝大部分论点。 不过,我认为她说得有点过了,而且将她的一些个人看法当作事实来陈述。我觉得作为程序员,对于那些内容我们需要更坦诚,所以我要对她的一些观点进行反驳。

整数除法怎么了?

作者对于整数除法的观点是“整数除法的行为会迷惑初学者”。的确,它会!但是什么东西不让初学者困惑?他们毕竟只是初学者啊。从初学者的角度来讨论整数除法并不是一件很有意义的事情,对于其他语言特性也是如此。

第 1 段(可获 1.58 积分)

实际上,整数除法的行为非常有用。我的辩解是在绝大部分情况下,它的表现符合人们的期望。 理由很简单:当一个人在和整数打交道的时候,他常常是在解决一个和整数有关的问题。< The reason for it is simple: when one is working with integers, one often has a problem related to integers in the first place.>

我们也并不想引入疯狂的浮点运算,比如在将一系列数组下标和它们对应的数组元素zip到一起时。<trying to zip a list of indices with their corresponding array elements.>

性能甚至不是重点; 浮点数要比整数复杂得多(即使对有经验的程序员来说,也很难正确使用.) 毕竟,它们的语义不同<they have different sematics>. I think that if one wants to escape the nice and friendly realm of closed operations, (试翻译:我认为如果一个人想跳出好用的类型闭合的运算),那么他应该使用强制类型转换<cast>来明确指出– 人们在编写C语言程序中正是这么做的。或者说不定引入一个新的运算符来进行浮点除法,我也不介意。

第 2 段(可获 1.89 积分)

自增/自减运算符怎么了?

自从Swift选择忽略自增自减运算符后,批判它们就成为非常流行的一件事。毕竟,苹果出品,必属精品,不是吗?

 不幸的是,Eevee 看起来犯了常见的 “++ 等价于+= 1” 谬误。很显然这是谬误,因为在文末甚至作者她自己也承认有些事情无法通过“+= 1“来实现,例如,将不能随机寻址的累加器增大。(译者注:例如累加寄存器只能通过指令来增减1这种情况)

但是看,还有更直接的论点: ++和-- 运算符甚至算不上“一个” 运算符。这些运算符前置或后置,效果是有细微区别的。常用的语义下,前置版本的求值结果是已经改变的表达式的值< the prefix ones evaulate to the already-modified expression>,而后置版本的值是表达式的原始值。 (运算符拥有这样的区别)在某些情况下会提供很大的便利,正如在不同的上下文<contexts>中,code might require the value of one state or another.因此拥有两个版本的运算符有可能会使得代码更简洁,并减少“差1错误”<off-by-one errors>。 因此,不能简单地说“++相当于+= 1“, 因为它本来就是不对的: 至少(两种++之间)有一种不等价于"+=1"。特别是C语言中,它不等价于后缀自增运算符。

第 3 段(可获 2.64 积分)

花括号和空格怎么了? (还有分号)

现在,让我们抬出二营长的意大利炮吧。那篇博文抱怨花括号括住的语句块和基于缩进的语句分组是等价的,因此允许这两种方式同时存在是冗余的。博文还提到用分号来终结语句也是冗余的,应该将分号换成换行符号<newlines>。然而这个说法真的很不正确。空格是方便人眼阅读的,而花括号是为了编译器的。在对空格敏感的编程语言中,自动缩进根本不可能实现,使人头疼。我不是Python专家,但是我已经好几次陷入了难以debug的境况,而我只是在重构的时候复制粘贴了几次,代码就表现出错误的行为来,因为缩进不对应应该使用的缩进级别。

第 4 段(可获 1.68 积分)

至于分号: 你不能把每一个换行都解释为分号一样的作用,因为这样做的话换行就对上下文敏感了。举个例子,在一个函数声明<declaration>后, 一个换行并不暗示语句就该结束了。同时,现在词法分析<lexing>也对换行敏感了, 解析起来会成一团乱麻,这样写起代码来简直像爆菊一样酸爽<pain in the ass>,更不要说要正确编写代码了。

作者在抱怨类型优先的语法<type-first syntax>使解析<parsing>变得困难之后又立马倡议加上这个不良特性<misfeature>,真令人丈二摸不着头脑。

再说了,将换行看成语句的结尾标志对于人类来说是难以正确记忆的,然而人们乍一看可能还会觉得蛮清爽的呢。举个例子,这段代码是干什么的?

第 5 段(可获 1.53 积分)
return

1 + 2

这段代码要return unit呢,还是return 3呢?取决于换行是否被当作语句分隔符。  呕!<Blargh.>

太长;不看:(TL;DR:) C语言的设计者可不是大笨蛋。的确,C语言的设计从多方面体现了四十年前 “运行速度高于一切”的理念, 但是将所有的设计理念扫进垃圾堆里也是不对的。我强调的三点显然不是短视– 相反,这些理念在程序员在现实世界中每日遇到的问题上展现了伟大的远见。

第 6 段(可获 1.31 积分)

文章评论

安得鲁
即使我算是能读懂作者在说些什么,因为我并不是C语言编译器/底层细节专家,很多微妙的东西我也说不上来。
青岛访客
闲人才有空批判