<程序设计实践>一点摘录

名字
一个变量的作用域越大，他的名字携带的信息就应该越多。
全局变量使用说明性的名字，局部变量使用短名字。
一个判断应该尽量接近他所对应的动作。也就是说，一旦通过了某个判断，就应该马上做对应的事情。
把数定义为常数，不要定义为宏。整数常数可以用枚举语句声明，不要用#define。
也可以用const，不过不能用作数组的界。


数据结构弄清楚3个：链表，树，散列表


如何通过堆栈来获取信息。


键入前仔细读一读。一个有效的但却没有受到足够重视的排错技术，那就是非常仔细地阅读代码，
仔细想一段时间，但是不要急于去做修改。出错时最大的诱惑就是赶快去用键盘，立刻开始
修改程序，看看错误是否马上就能烟消云散。


把错误弄成可以重现的。设法构造输入或者参数设置，使自己能够可靠的再现问题。然后再做
总结，把有关步骤包装起来，使你通过一个按钮或几次按键就可以运行它。


grep这样的模式匹配工具对于在正文中检索真是无价之宝。


写记录文件，当程序垮台时，这个文件里记录了垮台前的情况。


用条件编译不太好，例如：
#ifdef DEBUG
printf(...)
#endif
用一个带常量条件的正规的条件语句也能把事情做得同样的好：
enum {DEBUG=0};
...
if (DEBUG){
printf(...)
}
如果DEBUG=0，大多数编译系统对这段程序不会产生什么目标代码。
my comment: 这不正是我碰到的问题么？程序中满是#if语句，最后导致开关打开时，
可能程序就不能编译了。而用作者的方法，正好解决这个问题。不过要


如果需要修改一个程序去适应某个新情况，不应该以程序的一个新副本作为出发点。
应该设法调整现存的代码。对于一个程序，只要可能，应该只存在唯一的一套源程序。
应该保持代码里不出现#ifdef，这种做法每次将你的代码变得更具有可移植性，
而不是变得更特殊。


程序中讨论了#ifdef的缺点。确实，这些情况也是我遇到的，也是我说担心的副作用。


把系统依赖性局限在独立的文件里。一个文件对应一个系统。


记法一章节可以用另外一种方式来描述串口通讯协议，解析以及打包发送的过程。
将混乱的局面，一下变成清晰异常。


这本书提供了一些有效的建议，例如：不要用#ifdef的提法，就和我的感觉不谋而合；
而记法，将我对串口通讯程序的处理方法，提供了另外一种思考方法，可能是更清晰的方法。
数据结构，文章只仔细描述了数组、链表、树、散列表，而且只描述了最主要的用法，
我想，这对处理绝大多数问题也足够了；其中对于如何排错，我想和《代码大全》
中的一些建议基本相同。
最后，我想这本书尚未触及的：模式，重构，解耦、自动化的单元测试，
我对这些更感兴趣，这些不是语言级的，而是系统级，或者管理级，一但用好，
对软件质量和产出率产生的变化是本质性的变化。
当然，并不是说语言级的内容就不重要，他是基础。
我从直觉中认为：模式是创造容易维护的软件结构的正解，而自动化的单元测试
是维持软件良好结构的方法。