《代码整洁之道》笔记之函数

《代码整洁之道》笔记之函数
作者给出了⼏个评判函数好坏的标准：
短⼩
作者给的函数合理长度是⼩于15⾏，⽬标是每个函数都⼀⽬了然，每个函数都会把你依次带到下⼀个函数中去。

if、else、while语句等其中的代码快应该只有⼀⾏。

该⾏⼤抵应该是⼀个函数的调⽤语句。

这样不但能保持函数短⼩，⽽且因为块内调⽤的函数拥有较具说明⾏的名称，从⽽增加了⽂档上的价值函数的缩进曾不该多余两层，这样函数更容易理解。

只做⼀件事
从我接触编程开始，这条规则反反复复听了很多遍：函数应该做⼀件事，做好这件事，只做这⼀件事。

问题是那件事是什么，函数到底做了⼀件事还是做了⼏件事。

⽐如⼀个名为write_text_to_file(char *filename)的函数，它在其中会打开⼀个⽂件，写⼊⽂本到这个⽂件，然后关闭⽂件流。

这算⼏件事？
作者如是说：如果函数只是做了该函数名下同⼀抽象层上的步骤，则函数还是只做了⼀件事。

这样就好分辨的多。

我的理解是：write_text_to_file函数⾥⾯调⽤的⼏个函数，fopen、fwrite、fclose都是同⼀抽象层的，这算是只做了⼀件事，如果调⽤了更上层的delete_file函数，这样就算两件事了。

不知道这样理解有没错。

switch语句的正确使⽤
学习过《windows程序设计》的⼈肯定都写过这样的代码：
switch(uMsg)
{
case WM_DESTORY:
//xxxxxxx
break;
case WM_CREATE:
//xxxxxxx
break;
}
在其中对WINDOWS窗⼝的消息进⾏判断，然后处理。

没什么封装的话，就是直接写在case和break之间，⼀⼤坨。

有了点封装，会把要执⾏的代码写到独⽴的函数⾥，在收到消息时进⾏调⽤。

还可以弄个消息表，这样只需要在for循环中就完成了对应消息的处理，除⾮是写框架时才会这么做，⼀般都没这么多消息要处理。

有了⾯向对象还可以利⽤继承和多态机制来简化代码，参看：
作者这么说switch：对于switch语句，我的规矩是如果只出现⼀次，⽤于创建多态对象，⽽且隐藏在某个继承关系中，在系统其他部分看不到，就能容忍
对于switch他也没说绝对，后来⼜补充说：要就事论事
函数的名称
函数名别怕长，命名⽅式要在模块中进⾏统⼀。

做到让看代码的⼈⾃⼰可以通过函数名就能⼤概弄明⽩函数是⼲嘛的，这样就到位了，也就是他最后说的“深合⼰意”
函数的参数
书中说最理想的函数参数是没有参数，其次是⼀个，再次是两个，如果有了三个以上的参数，就说明这个函数需要传递对象作为参数了。

我觉得这个更多适合的是⾯向对象编程，像⾯向过程编程，有些时候没参数活⼉没法⼲，难道哪个⽂件都弄⼀⼤堆静态函数，再弄静态变量放在⽂件中？我不怎么习惯这样。

等我看完lua的源码再谈这个吧
然后是⼀些建议：
使⽤异常替代返回错误码
相对与返回错误码，这是更好的做法。

有异常就⽤异常吧
如何正确编写异常处理
对异常没有太多经验，只停留在会⽤的层⾯，就不多说了
避免重复
⼀般第⼀遍编写代码，会有不少冗余重复的代码。

再写⼀遍就是了。

如何编写出优秀的代码
以前代码写的⼜烂⼜难看，设计的⼜丑陋（现在设计也很糟糕），我向⼀位有经验的程序员请教，他说你重新再写⼀遍就好了，多写⼏次，总能写好的。

后来我就按照他的话重新写了遍当时的代码，果然好看多了。

后来每当遇到不满意的代码，都会重新写⼀下，慢慢的就有了进步。

现在有时重写⼀次就能写出满意的代码，有时得写三次。

这与对所使⽤的技术是否了解有关系。

对所运⽤的技术越熟悉，⼀次性写好的⼏率就越⾼。

书中对写出好的代码的建议也是重复编写，当然，加上这些规则对⾃⼰的代码进⾏审查，会写的更好。