《什么是好的程序》由会员分享，可在线阅读，更多相关《什么是好的程序（11页珍藏版）》请在金锄头文库上搜索。
1、什么是好的程序员？是不是懂得很多技术细节？还是懂底层编程？还是编程速度比较快？我觉得都不是。对于一些技术细节来说和底层的技术，只要看帮助，查资料就能找到，对于速度快，只要编得多也就熟能生巧了。我认为好的程序员应该有以下几方面的素质：1、有专研精神，勤学善问、举一反三。2、积极向上的态度，有创造性思维。3、与人积极交流沟通的能力，有团队精神。4、谦虚谨慎，戒骄戒燥。5、写出的代码质量高。包括：代码的稳定、易读、规范、易维护、专业。这些都是程序员的修养，这里我想谈谈“ 编程修养 ” ，也就是上述中的第5 点。我觉得，如果我要了解一个作者，我会看他所写的小说，如果我要了解一个画家，我会看他所画的图画
2、，如果我要了解一个工人，我会看他所做出来的产品，同样，如果我要了解一个程序员，我想首先我最想看的就是他的程序代码，程序代码可以看出一个程序员的素质和修养，程序就像一个作品，有素质有修养的程序员的作品必然是一图精美的图画，一首美妙的歌曲，一本赏心悦目的小说。我看过许多程序，没有注释，没有缩进，胡乱命名的变量名，等等，等等，我把这种人统称为没有修养的程序，这种程序员，是在做创造性的工作吗？不，完全就是在搞破坏，他们与其说是在编程，还不如说是在对源程序进行“ 加密 ” ，这种程序员，见一个就应该开除一个，因为他编的程序所创造的价值，远远小于需要在上面进行维护的价值。程序员应该有程序员的修养，那怕再累
3、，再没时间，也要对自己的程序负责。我宁可要那种动作慢，技术一般，但有良好的写程序风格的程序员，也不要那种技术强、动作快的“搞破坏 ” 的程序员。有句话叫“ 字如其人 ” ，我想从程序上也能看出一个程序员的优劣。因为，程序是程序员的作品，作品的好坏直截关系到程序员的声誉和素质。而“ 修养 ” 好的程序员一定能做出好的程序和软件。有个成语叫 “ 独具匠心 ” ，意思是做什么都要做得很专业，很用心，如果你要做一个“ 匠” ，也就是造诣高深的人，那么，从一件很简单的作品上就能看出你有没有“ 匠” 的特性，我觉得做一个程序员不难，但要做一个“ 程序匠 ” 就不简单了。编程序很简单，但编出有质量的程序就难
4、了。我在这里不讨论过深的技术，我只想在一些容易让人忽略的东西上说一说，虽然这些东西可能很细微，但如果你不注意这些细微之处的话，那么他将会极大的影响你的整个软件质量，以及整个软件程的实施，所谓“ 千里之堤，毁于蚁穴” 。“ 细微之处见真功” ，真正能体现一个程序的功底恰恰在这些细微之处。这就是程序员的 编程修养。我总结了在用C/C+ 语言（主要是C 语言）进行程序写作上的三十二个 “ 修养 ” ，通过这些，你可以写出质量高的程序，同时也会让看你程序的人渍渍称道，那些看过你程序的人一定会说：“ 这个人的编程修养不错” 。01、版权和版本02、缩进、空格、换行、空行、对齐03、程序注释04、函数的
5、inout 参数05、对系统调用的返回进行判断06、if 语句对出错的处理07、头文件中的#ifndef 08、在堆上分配内存09、变量的初始化10、h 和 c 文件的使用11、出错信息的处理12、常用函数和循环语句中的被计算量13、函数名和变量名的命名14、函数的传值和传指针15、修改别人程序的修养16、把相同或近乎相同的代码形成函数和宏17、表达式中的括号18、函数参数中的const 19、函数的参数个数20、函数的返回类型，不要省略21、goto 语句的使用22、宏的使用23、static 的使用24、函数中的代码尺寸25、typedef 的使用26、为常量声明宏27、不要为宏定义加分号
6、28、|和 ha = ( ha * 128 + *key+ ) % tabPtr-size; 有空格和没有空格的感觉不一样吧。一般来说，语句中要在各个操作符间加空格，函数调用时，要以各个参数间加空格。如下面这种加空格的和不加的：if (hProc=OpenProcess(PROCESS_ALL_ACCESS,FALSE,pid)=NULL) if ( ( hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid) ) = NULL ) iii) 换行。不要把语句都写在一行上，这样很不好。如：for(i=0;i9) 我拷，这种即无空格，又无换行的程序在
7、写什么啊？加上空格和换行吧。for ( i=0; i 9 ) 好多了吧？有时候，函数参数多的时候，最好也换行，如：CreateProcess( NULL, cmdbuf, NULL, NULL, bInhH, dwCrtFlags, envbuf, NULL, 条件语句也应该在必要时换行：if ( ch = 0 | ch = a | ch = A | ch name; 不！请不要这样做。你应该先判断一下传进来的那个指针是不是为空。如果传进来的指针为空的话，那么，你的一个大的系统就会因为这一个小的函数而崩溃。一种更好的技术是使用断言（assert），这里我就不多说这些技术细节了。当然，如果是在C
8、+中，引用要比指针好得多，但你也需要对各个参数进行检查。写有参数的函数时，首要工作，就是要对传进来的所有参数进行合法性检查。而对于传出的参数也应该进行检查，这个动作当然应该在函数的外部，也就是说，调用完一个函数后，应该对其传出的值进行检查。当然，检查会浪费一点时间，但为了整个系统不至于出现“ 非法操作 ” 或是 “Core Dump ”的系统级的错误，多花这点时间还是很值得的。5、对系统调用的返回进行判断继续上一条，对于一些系统调用，比如打开文件，我经常看到，许多程序员对fopen 返回的指针不做任何判断，就直接使用了。然后发现文件的内容怎么也读出不，或是怎么也写不进去。还是判断一下吧：fp
9、= fopen(“log.txt“, “a“); if ( fp = NULL ) printf(“Error: open file errorn“); return FALSE; 其它还有许多啦，比如：socket 返回的 socket 号， malloc 返回的内存。请对这些系统调用返回的东西进行判断。6、if 语句对出错的处理我看见你说了，这有什么好说的。还是先看一段程序代码吧。if ( ch = 0 return ( FALSE ); /* 正常处理代码*/ 这样的结构，不是很清楚吗？突出了错误的条件，让别人在使用你的函数的时候，第一眼就能看到不合法的条件，于是就会更下意识的避免。7、
10、头文件中的#ifndef 千万不要忽略了头件的中的#ifndef ，这是一个很关键的东西。比如你有两个C 文件，这两个 C 文件都 include 了同一个头文件。而编译时，这两个C 文件要一同编译成一个可运行文件，于是问题来了，大量的声明冲突。还是把头文件的内容都放在#ifndef 和#endif 中吧。不管你的头文件会不会被多个文件引用，你都要加上这个。一般格式是这样的：#ifndef #define #endif 在理论上来说可以是自由命名的，但每个头文件的这个“ 标识 ” 都应该是唯一的。标识的命名规则一般是头文件名全大写，前后加下划线，并把文件名中的“. ”也变成下划线，如： std
11、io.h #ifndef _STDIO_H_ #define _STDIO_H_ #endif （BTW ：预编译有多很有用的功能。你会用预编译吗？）8、在堆上分配内存可能许多人对内存分配上的“ 栈 stack ”和“ 堆 heap” 还不是很明白。包括一些科班出身的人也不明白这两个概念。我不想过多的说这两个东西。简单的来讲，stack 上分配的内存系统自动释放，heap 上分配的内存，系统不释放，哪怕程序退出，那一块内存还是在那里。stack 一般是静态分配内存，heap 上一般是动态分配内存。由 malloc 系统函数分配的内存就是从堆上分配内存。从堆上分配的内存一定要自己释放。用 fre
12、e 释放，不然就是术语“内存泄露 ” （或是 “ 内存漏洞 ” ） Memory Leak 。于是，系统的可分配内存会随malloc 越来越少，直到系统崩溃。还是来看看“ 栈内存 ” 和“ 堆内存 ” 的差别吧。栈内存分配char* AllocStrFromStack() char pstr100; return pstr; 堆内存分配char* AllocStrFromHeap(int len) char *pstr; if ( len = 0 ) return NULL; return ( char* ) malloc( len ); 对于第一个函数，那块pstr 的内存在函数返回时就被系
13、统释放了。于是所返回的char* 什么也没有。而对于第二个函数，是从堆上分配内存，所以哪怕是程序退出时，也不释放，所以第二个函数的返回的内存没有问题，可以被使用。但一定要调用free 释放，不然就是Me mory Leak ！在堆上分配内存很容易造成内存泄漏，这是C/C+ 的最大的 “ 克星 ” ，如果你的程序要稳定，那么就不要出现Memory Leak 。所以，我还是要在这里千叮咛万嘱付，在使用malloc 系统函数（包括calloc ，realloc）时千万要小心。记得有一个UNIX 上的服务应用程序，大约有几百的C 文件编译而成，运行测试良好，等使用时，每隔三个月系统就是down 一次，
14、搞得许多人焦头烂额，查不出问题所在。只好，每隔两个月人工手动重启系统一次。出现这种问题就是Memery Leak 在做怪了，在C/C+ 中这种问题总是会发生，所以你一定要小心。一个Rational 的检测工作 Purify ，可以帮你测试你的程序有没有内存泄漏。我保证，做过许多C/C+ 的工程的程序员，都会对malloc 或是 new 有些感冒。当你什么时候在使用 malloc 和 new 时，有一种轻度的紧张和惶恐的感觉时，你就具备了这方面的修养了。对于 malloc 和 free 的操作有以下规则：1) 配对使用，有一个malloc ，就应该有一个free。 （C+中对应为new 和 de
15、lete）2) 尽量在同一层上使用，不要像上面那种，malloc 在函数中，而free 在函数外。最好在同一调用层上使用这两个函数。3) malloc 分配的内存一定要初始化。free 后的指针一定要设置为NULL 。注：虽然现在的操作系统（如：UNIX和 Win2k/NT ）都有进程内存跟踪机制，也就是如果你有没有释放的内存，操作系统会帮你释放。但操作系统依然不会释放你程序中所有产生了Memory Leak的内存，所以，最好还是你自己来做这个工作。（有的时候不知不觉就出现M emory Leak 了，而且在几百万行的代码中找无异于海底捞针，Rational 有一个工具叫Puri fy，可能很
16、好的帮你检查程序中的Memory Leak ）9、变量的初始化接上一条，变量一定要被初始化再使用。C/C+ 编译器在这个方面不会像JAVA 一样帮你初始化，这一切都需要你自己来，如果你使用了没有初始化的变量，结果未知。好的程序员从来都会在使用变量前初始化变量的。如：1) 对 malloc 分配的内存进行memset 清零操作。（可以使用calloc 分配一块全零的内存）2) 对一些栈上分配的struct 或数组进行初始化。 （最好也是清零）不过话又说回来了，初始化也会造成系统运行时间有一定的开销，所以，也不要对所有的变量做初始化，这个也没有意义。好的程序员知道哪些变量需要初始化，哪些则不需要。如：以下这种情况，则不需要。char *pstr; /* 一个字符串*/ pstr = ( char* ) malloc( 50 ); if ( pstr = NULL ) exit(0); strcpy( pstr, “Hello W
