程序员应该有程序员的修养，那怕再累，再没时间，也要对自己的程序负责。我宁可要那种动作慢，技术一般，但有良好的写程序风格的程序员，也不要那种技术强、动作快的“搞破坏”的程序员。有句话叫“字如其人”，我想从程序上也能看出一个程序员的优劣。因为，程序是程序员的作品，作品的好坏直截关系到程序员的声誉和素质。而“修养”好的程序员一定能做出好的程序和软件。
有个成语叫“独具匠心”，意思是做什么都要做得很专业，很专心，假如你要做一个“匠”，也就是造诣高深的人，那么，从一件很简单的作品上就能看出你有没有“匠”的特性，我觉得做一个程序员不难，但要做一个“程序匠”就不简单了。编程序很简单，但编出有质量的程序就难了。
一、if 语句对出错的处理
我看见你说了，这有什么好说的。还是先看一段程序代码吧。
　　if ( ch >= ′0′ && ch <= ′9′ ){
　　　　/* 正常处理代码 */
　　}else{
　　　　/* 输出错误信息 */
　　　　printf("error ...... ");
　　　　return ( FALSE );
　　}
这种结构很不好，非凡是假如“正常处理代码”很长时，对于这种情况，最好不要用else。先判定错误，如：
　　if ( ch < ′0′ ch > ′9′ ){
　　　　/* 输出错误信息 */
　　　　printf("error ...... ");
　　　　return ( FALSE );
　　}
/* 正常处理代码 */
　　......
这样的结构，不是很清楚吗？突出了错误的条件，让别人在使用你的函数的时候，第一眼就能看到不合法的条件，于是就会更下意识的避免。
二、不要忽略Warning
对于一些编译时的警告信息，请不要忽视它们。虽然，这些Warning不会妨碍目标代码的生成，但这并不意味着你的程序就是好的。必竟，并不是编译成功的程序才是
正确的
，编译成功只是万里长征的第一步，后面还有大风大浪在等着你。从编译程序开始，不但要改正每个error，还要修正每个warning。这是一个有修养的程序员该做的事。
一般来说，一面的一些警告信息是常见的：
　　1）声明了未使用的变量。（虽然编译器不会编译这种变量，但还是把它从源程序中注释或是删除吧）
　　2）使用了隐晦声明的函数。（也许这个函数在别的C文件中，编译时会出现这种警告，你应该这使用之前使用extern要害字声明这个函数）
　　3）没有转换一个指针。（例如malloc返回的指针是void的，你没有把之转成你实际类型而报警，还是手动的在之前明显的转换一下吧）
　　4）类型向下转换。（例如：float f = 2.0; 这种语句是会报警告的，编译会告诉你正试图把一个double转成float，你正在阉割一个变量，你真的要这样做吗？还是在2.0后面加个f吧，不然，2.0就是一个double，而不是float了）
三、书写Debug版和Release版的程序
程序在开发过程中必然有许多程序员加的调试信息。我见过许多项目组，当程序开发结束时，发动群众删除程序中的调试信息，何必呢？为什么不像VC++那样建立两个版本的目标代码？一个是debug版本的，一个是Release版的。那些调试信息是那么的宝贵，在日后的维护过程中也是很宝贵的东西，怎么能说删除就删除呢？
利用预编译技术吧，如下所示声明调试函数：
　　#ifdef DEBUG
　　　　void TRACE(char* fmt, ...)
　　　　{
　　　　　　......
　　　　}
　　#else
　　　　#define TRACE(char* fmt, ...)
　　#endif
于是，让所有的程序都用TRACE输出调试信息，只需要在在编译时加上一个参数“-DDEBUG”，如：
　　cc -DDEBUG -o target target.c
于是，预编译器发现DEBUG变量被定义了，就会使用TRACE函数。而假如要发布给用户了，那么只需要把取消“-DDEBUG”的参数，于是所有用到TRACE宏，这个宏什么都没有，所以源程序中的所有TRACE语言全部被替换成了空。一举两得，一箭双雕，何乐而不为呢？
遵守规则都是为了三大目的
　　1、程序代码的易读性。
　　2、程序代码的可维护性，
　　3、程序代码的稳定可靠性。
好的软件产品绝不仅仅是技术，而更多的是整个软件的易维护和可靠性。
软件的维护有大量的工作量花在代码的维护上，软件的Upgrade，也有大量的工作花在代码的组织上，所以好的代码，清淅的，易读的代码，将给大大减少软件的维护和升级成本。