一个优秀的提交应该包含什么

首先我们来听一个令人恶心的例子。

你看到问题 F00-123 被解决了。这是关于一个你自己很熟悉的子系统的Bug,所以直觉告诉你造成这个Bug最可能的原因。为了证实你的怀疑,你决定看看这个bug是怎么被解决的。你花了很长时间搜索了整个版本历史,直到把这个bugfix的范围缩小到了4个连续的提交,它们分别的提交信息是:dao小调整(dao tweaks)、moar、Fixes, 还有删除一些调试信息(remove debug stuff)。每个提交的修改集看起来都很大,多达十几个文件的几百处修改。“我艹尼@#$%%^&”,你准备骂娘但还是停住了,没有骂出你脑中那句最难听的粗口。”这个bugfix不应该超过三行代码!”。

胡言乱语之LINK、DEFINE、DECLARE、EXTERN、STATIC

最早的C是没有声明的,只有定义,声明主要是提供给连接器(link)用的,现在好像C编译器也用到声明。(这句话我不太确定,你当作耳旁风好了)

定义就是给出一个函数的明确功能,比如:

优质代码的十诫

DRY: Don’t repeat yourself.

DRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。