文章目录
第一章:前言
第二章:约定
第三章:开始任务
第四章:使用lint
第五章:使用make
第六章:优质无错编程
第七章:调试技术
第八章:其它更好的文档

第一章:前言

对于C语言,有人认为它已经落伍了.对于这个问题,仁者见仕,智者见智.的确,C++比C有更强大的诸多优势.但C++是建立在C之上的.这也是Herbert Schildt所著书在全世界畅销不衰的原因.更何况,要深入学习LINUX就必需要有相当的C功底.(这也是我搜集整理本文的根由:-)
现结合个人在编程中的体会,为使新手少走弯路,为老手锦上添花,因此无论你是使用C或C++编程,也无论你是程序设计的初学者还是成熟的专业人员,均会发现,本文将会对你有所收益.当然,我尽力写得清晰易懂,又不古板.
我爱C.(正如世人爱上帝一样:-)..

第二章:约定

专业的源程书写风格.
先看看世界级C大师的源程书写风格.如 Steve Maguire 就有许多不错的建议.

[]倡导使用易于理解的"匈牙利式"的命名约定.
所有的字符变量均以ch开始; 如: char ch_****;
所有的字节变量均冠以b; 如: byte b_****;
所有的长字变量均冠以l; 如: long l_****;
所有的指针变量均冠以P; 如: char *p_ch_****;
建议类型派生出的基本名字之后加上一个以大写字母开头的"标签".如:
分析 char **ppchMydata;
其让人一眼就能看出它代表一个指向字符指针Mydata的指针.
"匈牙利式"命名的最大不足是难念:-(( .但相对于不是总统演讲稿的C源程来说,这又算得了什么?想想看以下的数据命名:
char a,b,c;
long d,e,f;
.
.
.
(反正我是不会再看下去了...)

[]倡导规范书写.
如果你思如泉涌,而不去也不及顾虑书写格式,那也没关系.在将其交出去之前,用cb命令格式化你的源程.虽然源程的格式不会影响到你编译结果的正确性,但切记,能让其他的程序员能轻松地阅读它.否则没人会理你的.
关于cb命令的更多用法,可以用man cb来参考其手册页.
当然除了cb之外,还有更多更好的.但cb是你在任何UNIX(LINUX)上都找得到的.更何况它并不差.

第三章:开始任务

开始任务之前,先做个深呼吸!

[]其他文档你准备好了吗?
你是不是除了C源程之外一无所有了吗?兵马未动,粮草先行.你必须先清楚该程序所要完成的功能.在开始写程序之前,对程序的功能应有规范说明.书写规范书和确知程序功能的一个方法是先编写相应的操作手册.如果你是一人单干,劝你首先写需求书.切记切记,这对你意味着事半功倍的大好事.
一个实例:我计划为本行的信贷子功能模块打一个补丁.我用10周的时间用来写规划书,需求书,操作流程,使用说明等等文档.之后用2周的时间编写程序,在初步测试(1周)后递交给各信贷部门测试使用.然后根据反馈的信息再更改相应文档,并根据文档修改源程.6个月后发布正式版.

[]一定该遵循ANSI标准吗?
如果你仅使用ANSI的标准首标文件,恭喜你,你的程序有着全世界范围内的广泛支持和兼容.光明无限.但你必须在通用与专用之间做出取舍,对不起,我帮不了你.
我的原则是:核心用ANSI,界面按需而取.这样在转换平台时仅需另编用户界面而已.实用至上嘛.
附:ANSI 标准C头文件

是不是很寒酸?

[]再续前缘?
在得到新任务之后并在开始该新任务之前应马上回想有哪些是曾经拥有的.旧调重弹远比另起炉灶来的高效与环保.

[]是否该有自已的库?
我的答案是应该有自已的特色库,并与ANSI兼容.与3.8不同的是,你仅需在源程序之后附上自已的专用库就可以了.其次在有了自已的库后,源码会很精炼的.不用去羡慕别人了吧.

[]要学会条件编译.注意你的平台特性.(高手的标志?)
除非你确定你要写的程序是在某特定的OS特定的硬件平台而量身定做.否则应注意数据类型的长度,精度都是不同的,不要想当然.有时甚至是不同的编译器的差异都要考虑考虑.

....
....(欢迎您来充实此处空白)
....

好了,在任务中,又有哪些细节呢?

[]我是不是葛郎台?
不要那么吝啬.在源程序中加入详尽的注释以使自己和他人即使在许多年以后仍能读明白它是什么样的程序.
用注释行分离各个函数.

[]删除不需要的代码时要小心.
一个好建议是:使用#ifdef DEL,而不是简单地注释掉甚至是粗暴地直接dd.如果你是使用/* ... */,但一旦要删除的代码有很多行,或注释中以有注释时,这就可能不那么好使了.

[]如何给源程序文件命名?
表现特色且不与任何原有应用名相同.一个简单地方法就是试试看,系统有什么样地反应?

[]一次只修改一个地方.

[]一次只编写一个单一功能的函数。

[]编写通用程序.
只有当程序编写完,并且完成了所需要的性能要求之后,再反过头来优化该程序.

[]不要使用a.out作为结果.你大可以使用与源程相同的可执行文件名.

[]是否一定要用VI编辑?
LINUX下有许多专用编程编辑器.它们能使你有更高的效率和更低的低级输入错误,但我还是要劝你至少要熟练掌握VI.毕竟VI遍地开花.

[]协同作业.请相信,你不是在孤军作战.因此,你有必要熟练掌握一些其它的工具.如

....
....(欢迎您来充实此处空白)
....

第四章:使用lint

lint没有你想象中的那样糟糕.相反,一旦源程序形成了没有LINT错误的形式,将很容易保持下去,并享受到如此而带来的好处.

[]在cc(gcc)之前就应使用LINT.
lint是一语法检查程序,对于这个多嘴的婆婆来说,你应有足够的耐心.虽然你知道自已在干什么,但在CC之前使用LINT总是一个好习惯.

[]lint有哪些特色?
在编译之前使用lint的重要原因是LINT不但能发现ANSI C中的语法错误,而且也能指出潜在的问题或是难于移植于另一机器的代码问题.除了能指出简单语法错误之外,LINUT还能基于以下原因指