作者给出了几个评判函数好坏的标准：

• 短小
  作者给的函数合理长度是小于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循环中就完成了对应消息的处理，除非是写框架时才会这么做，一般都没这么多消息要处理。有了面向对象还可以利用继承和多态机制来简化代码，参看：http://www.cnblogs.com/shiweifu/archive/2011/04/12/2014136.html
  作者这么说switch：对于switch语句，我的规矩是如果只出现一次，用于创建多态对象，而且隐藏在某个继承关系中，在系统其他部分看不到，就能容忍
  对于switch他也没说绝对，后来又补充说： 要就事论事

• 函数的名称
  函数名别怕长，命名方式要在模块中进行统一。做到让看代码的人自己可以通过函数名就能大概弄明白函数是干嘛的，这样就到位了，也就是他最后说的“深合己意”

• 函数的参数
  书中说最理想的函数参数是没有参数，其次是一个，再次是两个，如果有了三个以上的参数，就说明这个函数需要传递对象作为参数了。我觉得这个更多适合的是面向对象编程，像面向过程编程，有些时候没参数活儿没法干，难道哪个文件都弄一大堆静态函数，再弄静态变量放在文件中？我不怎么习惯这样。等我看完lua的源码再谈这个吧

然后是一些建议：

• 使用异常替代返回错误码
  相对与返回错误码，这是更好的做法。有异常就用异常吧

• 如何正确编写异常处理
  对异常没有太多经验，只停留在会用的层面，就不多说了

• 避免重复
  一般第一遍编写代码，会有不少冗余重复的代码。再写一遍就是了。

• 如何编写出优秀的代码
  以前代码写的又烂又难看，设计的又丑陋（现在设计也很糟糕），我向一位有经验的程序员请教，他说你重新再写一遍就好了，多写几次，总能写好的。后来我就按照他的话重新写了遍当时的代码，果然好看多了。后来每当遇到不满意的代码，都会重新写一下，慢慢的就有了进步。现在有时重写一次就能写出满意的代码，有时得写三次。这与对所使用的技术是否了解有关系。对所运用的技术越熟悉，一次性写好的几率就越高。书中对写出好的代码的建议也是重复编写，当然，加上这些规则对自己的代码进行审查，会写的更好。