Unix C 编程问题精粹.docVIP

Unix C 编程问题精粹第一章:前言 第二章:约定 第三章:开始任务 第四章:使用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.如果你是使用/* ... */,但一旦要删除的代码有很多行,或注释中以有注释时,这就可能不那么好使了. []如何给源程序文件命名? 表现特色且不与任何