Writing Clean Code 读后感

最近花了一些时间看了这本书，书名是

《Writing Clean Code ── Microsoft Techniques for Developing Bug-free C Programs》

这里主要总结了一些里面的编程思想。

为空语句加上NULL

当需要使用空语句的时候，最好写上NULL, 比如：

if (music_on())
    NULL;
else
   turn_it_on();

参数类型相同的问题

如果函数中两个参数的类型相同，如果用户调用这个函数时错误替换了参数的顺序，就会出现问题。

比如

bool are_you_that_guy(int id, int year)

这里如果可以修改其中一个类型的话（比如把int改成short），当写反参数时，编译器会做出警告，进而可以避免这种问题。

代码查错

不要依赖测试人员帮你查出代码中的问题，在写代码的时候要尽量做单元测速，保证每个单元都没有问题，这样做似乎会花费大量精力，而且会拖延进度，但是对于最后是由很大好处的，要知道程序员一般会花大部分时间来解bug，让bug在摇篮中被扼杀是一个好事情。不过对于维护一堆庞大代码的程序员来说就不一样了。

再写代码的时候要善用ASSERT，做好一个DEBUG开关，当release给客户的时候将ASSERT去掉。ASSERT的作用是将真正的错误显露出来（比如向函数传入了一个NULL指针），断言的是真正的用法不当，而不是一般的错误（比如内存分配失败，返回NULL）。

使用lint等工具也可以帮忙分析代码中的问题。（我没用过，后面试试）。实际上使用GCC的Wall开关就可以得到很多warning，进而解除一些问题。

可以写两个不同版本的代码来查错，一个是效率较低的，用于验证的代码，另一个是需要release的代码。

对代码进行逐条跟踪，对于每一种情况进行单元测试，这一点可能很多人做不到。

代码风格

不要让函数既返回结果，又返回错误代码。最具表现性的是

int getchar ( void );

当正确的时候返回一个int。getchar为什么返回int而不是返回char，这让人感到不可思议，实际上int值是为错误的情况准备的，也就是EOF

EOF的定义：

It is a macro definition of type int that expands into a negative integral constant expression (generally, -1).

这里可以认为它是-1.所以这样一来就很容易出问题了。好的做法应该将数据传入到函数的括号中，函数调用正确与否赋给返回值，比如：

int getchar(char *char_val);

不要写稀奇古怪的代码

好的代码应该是具有可维护性的，因为总会有新手来维护你的代码。当你把所有

代码都挤在一行，比如这种类型：

plan = planA ? (planB ? planC : planX) : (planD ? planE : planY)

这样会让人摸不着头脑。应该将它们拆成if和else语句，如果if和else嵌套太深，那么就是自己的设计问题了。

实际上不要用类似名称的变量，比如planA和planB，很容易搞混。

不要随便改别人代码

这个条款看起来不可理喻，有时候也会该出问题，除非你进行了详尽的测试。

比如将 

int identity;
identity = whois(tanhangbo);
TELL(identity );

改成

TELL(whois(tanhangbo))

如果TELL的定义是

#define TELL(x) (x + x*2)

那么whois会被调用两次。

知错能改

当然了，最重要的准则，同一个错误不要犯两遍。

--------------------

需要注意的东西还是很多的，这里只是提到了一部分。

写代码的时候还是要多思考的，如何能写出好代码，容易维护，bug少。这本书还是不错的，推荐看一看。

为知笔记的内容发到博客园还是有点问题，其中代码格式化好之后再发上去，格式就没了。不过能够方便地发上去已经不错了。

来自为知笔记(Wiz)