Rise'blogs

有一阵子，公司疯传一封电邮，就是Google公司的办公室靓照。红红绿绿的熔岩灯，独具匠心的小装饰，特立独行的张帖画……一时大家艳慕不已。于是有一个逻辑流传开来：Google之所以这么牛，是他的办公室牛。如果所有的公司都和Google一样打扮办公室，创造性环境自然来了……你看Google！

Google诚然是一个了不起的公司，其独特的公司组织结构，项目管理形式，企业文化，虽然还没有经受时间检验，但确实如李开复所说一样：令人震惊。（本文且不论Google，有时间专门写一篇文章。）但众多程序员的心向神往之后，大部分人的表现，也着实令人失望。

想起高中，参加高考之前，一位老师介绍了一通全国各地名校。那时，我等也是羡慕得不得了，听完报告连续用功了十几天。可是，今天，大家“长大了”，面对Google，Microsoft等大公司养眼的办公环境，有什么反应呢？大部分人，除了流流口水，骂声娘外，很少见到能够如高中时代般，回去发奋图强，哪怕只认真个十天。

实际上，你可以再仔细看看Google的画片，那些诱人的东西真的是很难在我们自己身边做的吗？我的看法是，也难也不难。

不难之处在于，大部分图片中所示的，没什么贵重物品，熔岩灯，小人，气球，滑板车，办公室取一个有趣的名字……没有一件是特花钱的，而且几乎所有成熟公司，都具备做到的条件。

难在那里呢？难在你是站在那里光顾着羡慕呢，还是回去立刻从自己的座位做起，和GOOGLE的员工比比创造力呢？以下是流传的图案中得一张：

有那位觉得不具备把自己的小角落也搞成这样的能力？还有这张：

   立刻回去，把老婆孩子得玩具相片都弄过来，会比她逊？

这里的核心问题是：你有没有别人那样有想像力和行动力。

当然，限于各公司不同的财力，有的可能不易做到，象免费饮料啦，全部LCD啦。可是，真是这些小便宜和硬件吸引着全世界优秀人才都扑向Google吗？我相信希望和有创造力的人一起工作才是Google最重要的吸引力。仅仅站在那儿发狠，能够让自己有一点点进步吗？

好，回头说，看到Google等公司超级办公室的致命诱惑后该干什么？中国古人早说了：与其临渊羡鱼，不如退而织网。

还是一个Simon的故事。

　　有一次，Simon和一个程序员G谈为什么要离开上一个公司。

　　G说，“我原来在一个小组做struts;后来项目做完了，公司调我到另一个组去。那个组用国内某公司开发的集成开发系统，用工具拖拖拽拽就做完了。我觉得学不到东西，所以就走了。”

　　Simon问:“为什么学不到东西?”

　　他说:“拖拖拽拽不是把程序员变成傻瓜了吗?”

　　Simon问:“Visual C++开发工具也可以用拖拖拽拽完成很多工作，很久以前都得手写的;为什么没有人觉得那是把程序员变成傻瓜呢?”

　　他想了想说，那很多Java代码都在组件内，看不到。没有办法学到底层。

　　Simon问:“是吗?你觉得你struts掌握得怎么样?”

　　他说很熟。

　　Simon又问:“那你看过struts的源码吗?”

　　他愣住了，说没有。

　　于是Simon问G，那你用struts和用那个集成开发工具生成的库有什么不一样?

　　G没有办法回答Simon的问题。

　　抱着G一样的认识的程序员是很多的。这是个认识自己的问题。我们从各种信息渠道，不知道积累了多少先入为主的谬论而不自知。

　　认识自己是最困难的。造物主创造人类的时候，所给予的感知器官:眼、鼻、耳、肤，全部都是一致对外的。这是一个适合认识世界，但不适合认识自己的机制。萦绕在大脑中的，始终是自己的“一厢情愿”。我也和那位G一样，经常随时会自己或被别人发现思想中的自相矛盾，有时羞愧得想要蜷成一团。

　　要认识自己，所需要的是勇气和智慧。随着年龄的增长，最大的益处就是能够开始有勇气反省自己，有时用一点自嘲，让自己变得轻松一点。

　　希望和大家共勉:慎独而三省其身。

1. 每天Review一个系统的设计。Review的时候记住几个关键字：Compatibility，Performance，Fail-over，Load Balance，Redundency，Deployment，Backup/Restor，i18n。
2. 每天Review一个Bug。
3. 每天Review一个程序文件。
4. 每天下载一个开源产品，做一次安装。

最近在学C#，写个保护眼睛的程序（就是过一段时间关下显示器，锁下屏幕之类的）做为练习。以下是关闭显示器的代码，网上好像还没有，在这贴上来，希望对大家有帮助。

与多线程相关的两个常见的需要解决的问题是：临界资源保护和线程间的同步依赖，每一种语言都提供了自己的一套设施（有的语言可能需要借助OS的API）来解决这两个问题，C#提供了更方便灵活的解决方案，首先C#可以允许我们在不同的级别上加锁，也就是说我们可以控制加锁的粒度。其次，C#提供了一套内置的线程安全的容器，方便我们的使用。

一.不同级别（Level）上的同步： 1.object level 同步 对应的class必须从ContextBoundObject继承(同步上下文context，使所有的方法调用能被截获)，并且在 class上运用SynchronizationAttribute 。

2.Method level 同步 System.Runtime.CompilerService空间包含的一些属性将影响CLR在运行期间的行为。特性MethodImplAttribute可以用于需要进行同步控制的方法上。

3.code segment level 同步 (1)Monitor类(主要是静态方法) Monitor.Enter(obj)//获得加在对象obj上的锁 ... Monitor.Exit(obj)//释放锁 //上面两句之间的代码相当于lock(obj){...}

Monitor.TryEnter(obj)//该方法立即返回，如果返回值为false，则接下来不需要Monitor.Exit(obj)。

//以下几个方法用于线程间的交互 ＝＝》 解决同步依赖 Monitor.Wait(obj)//等待脉冲消息。释放对象上的锁并阻塞当前线程，以后只有其它线程调用Pulse或PulseAll时才会给它再次获得锁的机会 Monitor.Pulse(obj)//发射脉冲消息( 只有得到锁后才能发射，而且发射不会自动释放锁) Monitor.PulseAll(obj)

注意： (1)Monitor 锁定对象，只能在Enter()和Exit()之间的代码块中调用Wait和Pulse

(2)不能在一个线程中获得锁，而在另一个线程中释放锁。这样会产生锁丢失。 获得锁和释放锁应该在同一个线程中完成。

(3)lock语句 lock(obj) { 需要进行同步的代码 }

(4)ReaderWriterLock类 实现单写多读程序的锁。 AcquireReaderLock()//当没有写程序线程占用锁时，就可获得锁 AcquireWriterLock()//当没有任何读写程序线程占用锁时，才可获得锁 ReleaseReaderLock() ReleaseWriterLock()

(5)ManualResetEvent Set()方法将状态设置为有信号 Reset()将其设置为无信号 WaitOne()将阻塞到其有信号为止，若调用WaitOne的时刻就是有信号的，将不会阻塞

(6)AutoResetEvent 与ManualResetEvent的区别是，AutoResetEvent.WaitOne()会自动改变事件对象的状态，即AutoResetEvent.WaitOne()每执行一次，事件的状态就改变一次。有信号-->无信号；无信号-->有信号

说明： (1)无论是Monitor还是lock、ReaderWriterLock都只对引用类型的对象有效，因为引用类型的对象有一个隐藏的sync#字段，该字段的作用就是作为加锁的标记。 (2)上述的各种设施中，只有Monitor 和ManualResetEvent/AutoResetEvent 能解决线程间的同步依赖问题，而其它的设施主要用于解决临界资源共享。

4.member level同步 (1)Interlocked类(主要是静态方法) 同步一个由许多线程共享的变量。 Decrement(ref int);//使变量减1 Increment(ref int);//使变量加1 //以上两个方法仅针对类int变量 Exchange(ref object, object);

(2)ThreadStaticAttribute 该特性用于修饰静态变量，被该特性修饰的静态变量在每个线程中都有自己的副本。

二.创建线程安全的对象 Hashtable h = Hashtable.Synchronized(new Hashtable()) ; ArrayList等容器也提供类似操作。

以前在同一个进程里，特别钟爱用Sleep(0)来做一些情况下的线程同步。譬如当线城池工作时，主线程使用Sleep(0)来等待线程池里所有的线程都完成运行。当线程池线程非常多的时候，这种方法确实是一种非常有效的节省cpu的方式，因为它节省了在线程里使用内核来进行同步的开销。而且很重要的，它运作的很好，可以说完全在我的控制之内。

然而在我换上了双核cpu后,问题出来了：Sleep(0)经常会比预期中更早返回。当初的设计代码根本没有考虑过多核/多cpu方式下的线程调度。

看来，速度和方便，还是难以两全其美。如果数据对同步敏感，还是不能偷工减料。

另外，在测试中发现非常奇怪的一点: 当线程池工作的时候，在任务管理器里设定该进程只能在一个cpu上运行的时候，该进程所占用的内存量急剧持续增长。而再设回允许在双核下调度时，内存量又开始缓慢持续减少^_^

Simon是一个软件公司技术总监。有一天，有一位程序员小A提出想要和Simon谈谈。小A工作5年了，程序写得很不错。他进到Simon的办公室，坐下，在Simon的对面。
Simon的桌子有点弧度，于是Simon挪动椅子，和他斜对面。Simon问他有什么事？
“我现在很困惑。我不知道是不是应该转行去做管理。”小A说。
“为什么？”Simon问。
“我看到一些媒体，还有一些认识的Leader都说只有做管理才有前途。”
Simon想了想。小A人很踏实，同时也很聪明，所参加的项目很有挑战性，但他一直做的不错，因此，薪水比同时进公司的员工已经高了20%。
“这样吧，我问你一个问题：现在公司开始执行10%淘汰制。你是一个10个人的组长，因此，你必须淘汰一个。这10个兄弟干得都不错，至少没有吊儿郎当的，跟你的关系都不错。现在的问题是：你准备淘汰那个？”
小A觉得这个问题很难回答。
Simon说：“这样吧，我换一个问题。你喜欢不希望成为作决定的那个人？”
这次小A回答得很快：“不喜欢。”
Simon说：“好，其实你自己已经回答了，你不应该去做管理，因为你根本不喜欢。做一件你不喜欢的事情，你会很不开心。”

和小A一样，其实几乎每个程序员几乎都会面临，或面临过这个问题。
管理是一个很好听好看的词，似乎只要和管理沾了边，就是高薪，荣誉，更广阔的出路。也许对，可我也看到过曾经的技术强人，做了所谓的经理多年后，居然找不到一份满意的工作。因为实际动手能力已经消退了。
所有想要做管理的程序员可以想一想：
管理是什么？管人吗？如果抱着这样的想法去做管理，一定头破血流。现在的时代，没有人愿意被看管的。即使是经理人，也是和人相处，并非凌驾于他人之上。想一想陆纯初，因为一封电邮就被秘书PK下马。
管理有什么用？其实如果大家都好好工作，所有的经理人都是多余的。现代的管理理论是经理人作为协调人，进而是教练。好的管理者应该低调，把荣誉让给干活的人。
管理者也未必比干活的人工资高。存这样想法的人是官本位。我和很多国外公司接触，他们的很多经理告诉我，他手下的高级工程师很多薪水远比他这个boss高，地位也稳固。而经理往往随着公司政局变化而动荡。而高级工程师往往稳得很。
当然，管理者也有很多乐趣，最主要的乐趣在于通过管理的技巧和有效的执行改变团队。但这些往往是隔山打牛的功夫，不是每个人都喜欢这样的工作。

我在包括CSDN内的很多技术论坛看到很多关于是要做管理还是技术的争执，所谓不能做一辈子技术的论调是我不屑于反驳的。但对于走向管理，大部分人是从是不是能挣更多钱（包括所谓前途，爽等），但很少见到有人考虑过是不是喜欢的问题。
实际上程序员们不妨问问自己：
你是希欢智商上的挑战呢，还是情商逆商上的挑战？
如果是前者，请把做技术作为终生追求。
如果是后者，可以试试走向管理。
如果都不喜欢……

过去有一位年轻和尚，一心求道，希望有日成佛。但是，多年苦修参禅，似乎没有进步。
有一天，他打听到深山中有一破旧古寺，住持某老和尚修炼圆通，是得道高僧。
于是，年轻和尚打点行装，跋山涉水，千辛万苦来到老和尚面前。
两人打起了机锋。
年轻和尚：请问老和尚，你得道之前，做什么？
老和尚：砍柴担水做饭。
年轻和尚：那得道之后，又做什么？
老和尚：还是砍柴担水做饭。
年轻和尚于是哂笑：那何谓得道？
老和尚：我得道之前，砍柴时惦念着挑水，挑水时惦念着做饭，做饭时有想着砍柴；得道之后，砍柴即砍柴，担水即担水，做饭即做饭。这就是得道。

翻译成程序员，编一个故事：
过去有一位程序员，一心想追求技术，希望有一天能成为顶级高手。但是，多年学习，似乎没有进步。
有一天，他打听到某高手，到了首都北京，其水平享誉业界，是公认的权威。
于是，程序员打点行装，从牙缝里挤出差旅费，坐火车来到北京，迷了几次路后，咬牙打的找到了高手。
两人开始探讨程序员应该怎么个人发展的问题。
程序员：请问高手，你在名声大震之前，干什么？
高手：在公司写程序。
程序员：成名之后呢？
高手：还是在公司写程序。
程序员于是哂笑：那有什么不一样？
高手：没什么不一样，不过我近来进步，做事情更专心了，不再老是想着写程序发不了财了。这样我就成了高手。

其实，写程序就是写程序。这本身就和前途啊，财富啊不直接关联。只不过时代使然，使它成为刚好是个待遇较好，也是较有机会的行业。因此，年轻一代涌向这个行业，只有一小部分人是兴趣使然。这样，我们所见到的，有毅力，沉得下心的人颇为难得。很多人，坐在电脑屏幕前，要么视为苦差事，要么东张西望，不能定心。如此哪能成功。

每一行都有自己的道，和尚想成佛，俗人想成功。但是不管是谁那行，都只有定心苦修，克服心魔才能有所建树。

也效仿古人写一偈：
一年两年刚入行，三年四年不值讲。
五六七年识门道，八九十年算登堂。

      什么是好的程序员？是不是懂得很多技术细节？还是懂底层编程？还是编程速度比较快？我觉得都不是。对于一些技术细节来说和底层的技术，只要看帮助，查资料就能找到，对于速度快，只要编得多也就熟能生巧了。

我认为好的程序员应该有以下几方面的素质：

　1、有专研精神，勤学善问、举一反三。

　2、积极向上的态度，有创造性思维。

　3、与人积极交流沟通的能力，有团队精神。

　4、谦虚谨慎，戒骄戒燥。

5、写出的代码质量高。包括：代码的稳定、易读、规范、易维护、专业。

这些都是程序员的修养，这里我想谈谈“编程修养”，也就是上述中的第5点。我觉得，如果我要了解一个作者，我会看他所写的小说，如果我要了解一个画家，我会看他所画的图画，如果我要了解一个工人，我会看他所做出来的产品，同样，如果我要了解一个程序员，我想首先我最想看的就是他的程序代码，程序代码可以看出一个程序员的素质和修养，程序就像一个作品，有素质有修养的程序员的作品必然是一图精美的图画，一首美妙的歌曲，一本赏心悦目的小说。

我看过许多程序，没有注释，没有缩进，胡乱命名的变量名，等等，等等，我把这种人统称为没有修养的程序，这种程序员，是在做创造性的工作吗？不，完全就是在搞破坏，他们与其说是在编程，还不如说是在对源程序进行“加密”，这种程序员，见一个就应该开除一个，因为他编的程序所创造的价值，远远小于需要在上面进行维护的价值。

程序员应该有程序员的修养，那怕再累，再没时间，也要对自己的程序负责。我宁可要那种动作慢，技术一般，但有良好的写程序风格的程序员，也不要那种技术强、动作快的“搞破坏”的程序员。有句话叫“字如其人”，我想从程序上也能看出一个程序员的优劣。因为，程序是程序员的作品，作品的好坏直截关系到程序员的声誉和素质。而“修养”好的程序员一定能做出好的程序和软件。

有个成语叫“独具匠心”，意思是做什么都要做得很专业，很用心，如果你要做一个“匠”，也就是造诣高深的人，那么，从一件很简单的作品上就能看出你有没有“匠”的特性，我觉得做一个程序员不难，但要做一个“程序匠”就不简单了。编程序很简单，但编出有质量的程序就难了。

我在这里不讨论过深的技术，我只想在一些容易让人忽略的东西上说一说，虽然这些东西可能很细微，但如果你不注意这些细微之处的话，那么他将会极大的影响你的整个软件质量，以及整个软件程的实施，所谓“千里之堤，毁于蚁穴”。

“细微之处见真功”，真正能体现一个程序的功底恰恰在这些细微之处。

这就是程序员的–编程修养。我总结了在用C/C++语言（主要是C语言）进行程序写作上的三十二个“修养”，通过这些，你可以写出质量高的程序，同时也会让看你程序的人渍渍称道，那些看过你程序的人一定会说：“这个人的编程修养不错”。

　　————————

　　　　

　　　　01、版权和版本

　　　　02、缩进、空格、换行、空行、对齐

　　　　03、程序注释

　　　　04、函数的[in][out]参数

　　　　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、不要为宏定义加分号

　　　　28、||和&&的语句执行顺序

　　　　29、尽量用for而不是while做循环

　　　　30、请sizeof类型而不是变量

　　　　31、不要忽略Warning

　　　　32、书写Debug版和Release版的程序

　　————————

1、版权和版本

——-

好的程序员会给自己的每个函数，每个文件，都注上版权和版本。

对于C/C++的文件，文件头应该有类似这样的注释：

/************************************************************************

• 
  

*　 文件名：network.c

• 
  

*　 文件描述：网络通讯函数集

• 
  

*　 创建人： Hao Chen, 2003年2月3日

• 
  

*　 版本号：1.0

• 
  

*　 修改记录：

• 
  

************************************************************************/

而对于函数来说，应该也有类似于这样的注释：

/*================================================================

• 
  

• 函 数 名：XXX
  

• 
  

• 参　　数：
  

• 
  

*　　　　type name [IN] : descripts

• 
  

• 功能描述:
  

• 
  

*　　　　…………..

• 
  

• 返 回 值：成功TRUE，失败FALSE
  

• 
  

• 抛出异常：
  

• 
  

• 作　　者：ChenHao 2003/4/2
  

• 
  

================================================================*/

这样的描述可以让人对一个函数，一个文件有一个总体的认识，对代码的易读性和易维护性有很大的好处。这是好的作品产生的开始。

2、缩进、空格、换行、空行、对齐

—————-

i) 缩进应该是每个程序都会做的，只要学程序过程序就应该知道这个，但是我仍然看过不缩进的程序，或是乱缩进的程序，如果你的公司还有写程序不缩进的程序员，请毫不犹豫的开除他吧，并以破坏源码罪起诉他，还要他赔偿读过他程序的人的精神损失费。缩进，这是不成文规矩，我再重提一下吧，一个缩进一般是一个TAB键或是4个空格。（最好用TAB键）

ii) 空格。空格能给程序代来什么损失吗？没有，有效的利用空格可以让你的程序读进来更加赏心悦目。而不一堆表达式挤在一起。看看下面的代码：

　　ha=(ha*128+*key++)%tabPtr->size;

　　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;i<len;i++) if((a<&acute;0&acute;||a>&acute;9&acute;)&&(a<&acute;a&acute;||a>&acute;z&acute;)) break;

　　

　　我拷，这种即无空格，又无换行的程序在写什么啊？加上空格和换行吧。　　

　　

　　for ( i=0; i<len; i++) {

　　　　if ( ( a < &acute;0&acute; || a > &acute;9&acute; ) &&

　　　　　　 ( a < &acute;a&acute; || a > &acute;z&acute; ) ) {

　　　　　　break;

　　　　}

　　}

　　好多了吧？有时候，函数参数多的时候，最好也换行，如：

　　CreateProcess(

　　　　　　　　　NULL,

　　　　　　　　　cmdbuf,

　　　　　　　　　NULL,

　　　　　　　　　NULL,

　　　　　　　　　bInhH,

　　　　　　　　　dwCrtFlags,

　　　　　　　　　envbuf,

　　　　　　　　　NULL,

　　　　　　　　　&siStartInfo,

　　　　　　　　　&prInfo

　　　　　　　　 );

　　条件语句也应该在必要时换行：

　　

　　if ( ch >= &acute;0&acute; || ch <= &acute;9&acute; ||

　　　　 ch >= &acute;a&acute; || ch <= &acute;z&acute; ||

　　　　 ch >= &acute;A&acute; || ch <= &acute;Z&acute; )

　　　　　　　　　

iv) 空行。不要不加空行，空行可以区分不同的程序块，程序块间，最好加上空行。如：

　　HANDLE hProcess;

　　PROCESS_T procInfo;

　　/* open the process handle */

　　if((hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid)) == NULL)

　　{

　　　　return LSE_MISC_SYS;

　　}

　　memset(&procInfo, 0, sizeof(procInfo));

　　procInfo.idProc = pid;

　　procInfo.hdProc = hProcess;

　　procInfo.misc |= MSCAVA_PROC;

　　return(0);

　　　　　　　　　

v) 对齐。用TAB键对齐你的一些变量的声明或注释，一样会让你的程序好看一些。如：

typedef struct pt_man_t {

　　int　　 numProc;　　/* Number of processes　　　　　　　　 */

　　int　　 maxProc;　　/* Max Number of processes　　　　　　 */

　　int　　 numEvnt;　　/* Number of events　　　　　　　　　　*/

　　int　　 maxEvnt;　　/* Max Number of events　　　　　　　　*/

　　HANDLE* pHndEvnt;　 /* Array of events　　　　　　　　　　 */

　　DWORD　 timeout;　　/* Time out interval　　　　　　　　　 */

　　HANDLE　hPipe;　　　/* Namedpipe　　　　　　　　　　　　　 */

　　TCHAR　 usr[MAXUSR];/* User name of the process　　　　　　*/

　　int　　 numMsg;　　 /* Number of Message　　　　　　　　　 */

　　int　　 Msg[MAXMSG];/* Space for intro process communicate */

} PT_MAN_T;

怎么样？感觉不错吧。

这里主要讲述了如果写出让人赏心悦目的代码，好看的代码会让人的心情愉快，读起代码也就不累，工整、整洁的程序代码，通常更让人欢迎，也更让人称道。现在的硬盘空间这么大，不要让你的代码挤在一起，这样它们会抱怨你虐待它们的。好了，用“缩进、空格、换行、空行、对齐”装饰你的代码吧，让他们从没有秩序的土匪中变成一排排整齐有秩序的正规部队吧。

　　　　　　　　　

3、程序注释

——

养成写程序注释的习惯，这是每个程序员所必须要做的工作。我看过那种几千行，却居然没有一行注释的程序。这就如同在公路上驾车却没有路标一样。用不了多久，连自己都不知道自己的意图了，还要花上几倍的时间才看明白，这种浪费别人和自己的时间的人，是最为可耻的人。

是的，你也许会说，你会写注释，真的吗？注释的书写也能看出一个程序员的功底。一般来说你需要至少写这些地方的注释：文件的注释、函数的注释、变量的注释、算法的注释、功能块的程序注释。主要就是记录你这段程序是干什么的？你的意图是什么？你这个变量是用来做什么的？等等。

不要以为注释好写，有一些算法是很难说或写出来的，只能意会，我承认有这种情况的时候，但你也要写出来，正好可以训练一下自己的表达能力。而表达能力正是那种闷头搞技术的技术人员最缺的，你有再高的技术，如果你表达能力不行，你的技术将不能得到充分的发挥。因为，这是一个团队的时代。

好了，说几个注释的技术细节：

i) 对于行注释（“//”）比块注释（“/* */”）要好的说法，我并不是很同意。因为一些老版本的C编译器并不支持行注释，所以为了你的程序的移植性，请你还是尽量使用块注释。

ii) 你也许会为块注释的不能嵌套而不爽，那么你可以用预编译来完成这个功能。使用“#if 0”和“#endif”括起来的代码，将不被编译，而且还可以嵌套。

4、函数的[in][out]参数

———–

我经常看到这样的程序：

FuncName(char* str)

{

　　int len = strlen(str);

　　…..

}

char*

GetUserName(struct user* pUser)

{

　　return pUser->name;

}

不！请不要这样做。

你应该先判断一下传进来的那个指针是不是为空。如果传进来的指针为空的话，那么，你的一个大的系统就会因为这一个小的函数而崩溃。一种更好的技术是使用断言（assert），这里我就不多说这些技术细节了。当然，如果是在C++中，引用要比指针好得多，但你也需要对各个参数进行检查。

写有参数的函数时，首要工作，就是要对传进来的所有参数进行合法性检查。而对于传出的参数也应该进行检查，这个动作当然应该在函数的外部，也就是说，调用完一个函数后，应该对其传出的值进行检查。

当然，检查会浪费一点时间，但为了整个系统不至于出现“非法操作”或是“Core Dump”的系统级的错误，多花这点时间还是很值得的。

5、对系统调用的返回进行判断

————–

继续上一条，对于一些系统调用，比如打开文件，我经常看到，许多程序员对fopen返回的指针不做任何判断，就直接使用了。然后发现文件的内容怎么也读出不，或是怎么也写不进去。还是判断一下吧：

　　fp = fopen(“log.txt”, “a”);

　　if ( fp == NULL ){

　　　　printf(“Error: open file errorn”);

　　　　return FALSE;

　　}

其它还有许多啦，比如：socket返回的socket号，malloc返回的内存。请对这些系统调用返回的东西进行判断。

6、if 语句对出错的处理

———–

我看见你说了，这有什么好说的。还是先看一段程序代码吧。

　　if ( ch >= &acute;0&acute; && ch <= &acute;9&acute; ){

　　　　/* 正常处理代码 */

　　}else{

　　　　/* 输出错误信息 */

　　　　printf(“error ……n”);

　　　　return ( FALSE );

　　}

这种结构很不好，特别是如果“正常处理代码”很长时，对于这种情况，最好不要用else。先判断错误，如：

　　if ( ch < &acute;0&acute; || ch > &acute;9&acute; ){

　　　　/* 输出错误信息 */

　　　　printf(“error ……n”);

　　　　return ( FALSE );

　　}

　　

　　/* 正常处理代码 */

　　……

这样的结构，不是很清楚吗？突出了错误的条件，让别人在使用你的函数的时候，第一眼就能看到不合法的条件，于是就会更下意识的避免。

7、头文件中的#ifndef

———-

千万不要忽略了头件的中的#ifndef，这是一个很关键的东西。比如你有两个C文件，这两个C文件都include了同一个头文件。而编译时，这两个C文件要一同编译成一个可运行文件，于是问题来了，大量的声明冲突。

还是把头文件的内容都放在#ifndef和#endif中吧。不管你的头文件会不会被多个文件引用，你都要加上这个。一般格式是这样的：

　　#ifndef　<标识>

　　#define <标识>

　　

　　……

　　……

　　

　　#endif

　　

<标识>在理论上来说可以是自由命名的，但每个头文件的这个“标识”都应该是唯一的。标识的命名规则一般是头文件名全大写，前后加下划线，并把文件名中的“.”也变成下划线，如：stdio.h

　　#ifndef STDIO_H

　　#define STDIO_H

　　

　　……

　　

　　#endif

　　

（BTW：预编译有多很有用的功能。你会用预编译吗？）　　

　　

8、在堆上分配内存

———

可能许多人对内存分配上的“栈 stack”和“堆 heap”还不是很明白。包括一些科班出身的人也不明白这两个概念。我不想过多的说这两个东西。简单的来讲，stack上分配的内存系统自动释放，heap上分配的内存，系统不释放，哪怕程序退出，那一块内存还是在那里。stack一般是静态分配内存，heap上一般是动态分配内存。

由malloc系统函数分配的内存就是从堆上分配内存。从堆上分配的内存一定要自己释放。用free释放，不然就是术语–“内存泄露”（或是“内存漏洞”）– Memory Leak。于是，系统的可分配内存会随malloc越来越少，直到系统崩溃。还是来看看“栈内存”和“堆内存”的差别吧。

　　栈内存分配

　　—–

　　char*

　　AllocStrFromStack()

　　{

　　　　char pstr[100];

　　　　return pstr;

　　}

　　

　　

　　堆内存分配

　　—–

　　char*

　　AllocStrFromHeap(int len)

　　{

　　　　char *pstr;

　　　　

　　　　if ( len <= 0 ) return NULL;

　　　　return ( char* ) malloc( len );

　　}

对于第一个函数，那块pstr的内存在函数返回时就被系统释放了。于是所返回的char*什么也没有。而对于第二个函数，是从堆上分配内存，所以哪怕是程序退出时，也不释放，所以第二个函数的返回的内存没有问题，可以被使用。但一定要调用free释放，不然就是Memory Leak！

在堆上分配内存很容易造成内存泄漏，这是C/C++的最大的“克星”，如果你的程序要稳定，那么就不要出现Memory Leak。所以，我还是要在这里千叮咛万嘱付，在使用malloc系统函数（包括calloc，realloc）时千万要小心。

记得有一个UNIX上的服务应用程序，大约有几百的C文件编译而成，运行测试良好，等使用时，每隔三个月系统就是down一次，搞得许多人焦头烂额，查不出问题所在。只好，每隔两个月人工手动重启系统一次。出现这种问题就是Memery Leak在做怪了，在C/C++中这种问题总是会发生，所以你一定要小心。一个Rational的检测工作–Purify，可以帮你测试你的程序有没有内存泄漏。

我保证，做过许多C/C++的工程的程序员，都会对malloc或是new有些感冒。当你什么时候在使用malloc和new时，有一种轻度的紧张和惶恐的感觉时，你就具备了这方面的修养了。

　　

对于malloc和free的操作有以下规则：

1. 配对使用，有一个malloc，就应该有一个free。（C++中对应为new和delete）
   

2. 尽量在同一层上使用，不要像上面那种，malloc在函数中，而free在函数外。最好在同一调用层上使用这两个函数。
   

3. malloc分配的内存一定要初始化。free后的指针一定要设置为NULL。　　
   

注：虽然现在的操作系统（如：UNIX和Win2k/NT）都有进程内存跟踪机制，也就是如果你有没有释放的内存，操作系统会帮你释放。但操作系统依然不会释放你程序中所有产生了Memory Leak的内存，所以，最好还是你自己来做这个工作。（有的时候不知不觉就出现Memory Leak了，而且在几百万行的代码中找无异于海底捞针，Rational有一个工具叫Purify，可能很好的帮你检查程序中的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 Wrold” );

但如果是下面一种情况，最好进行内存初始化。（指针是一个危险的东西，一定要初始化）

　　　　char *pstr;　/ 一个字符串数组 */

　　　　pstr = ( char** ) malloc( 50 );

　　　　if ( pstr == NULL ) exit(0);

　　　　

　　　　/* 让数组中的指针都指向NULL */

　　　　memset( pstr, 0, 50sizeof(char) );

　　　　

而对于全局变量，和静态变量，一定要声明时就初始化。因为你不知道它第一次会在哪里被使用。所以使用前初始这些变量是比较不现实的，一定要在声明时就初始化它们。如：

　　Links plnk = NULL;　/ 对于全局变量plnk初始化为NULL */

10、h和c文件的使用

———

H文件和C文件怎么用呢？一般来说，H文件中是declare（声明），C文件中是define（定义）。因为C文件要编译成库文件（Windows下是.obj/.lib，UNIX下是.o/.a），如果别人要使用你的函数，那么就要引用你的H文件，所以，H文件中一般是变量、宏定义、枚举、结构和函数接口的声明，就像一个接口说明文件一样。而C文件则是实现细节。

H文件和C文件最大的用处就是声明和实现分开。这个特性应该是公认的了，但我仍然看到有些人喜欢把函数写在H文件中，这种习惯很不好。（如果是C++话，对于其模板函数，在VC中只有把实现和声明都写在一个文件中，因为VC不支持export关键字）。而且，如果在H文件中写上函数的实现，你还得在makefile中把头文件的依赖关系也加上去，这个就会让你的makefile很不规范。

最后，有一个最需要注意的地方就是：带初始化的全局变量不要放在H文件中！

例如有一个处理错误信息的结构：

　　char* errmsg[] = {

　　　　/* 0 */　　　 “No error”,　　　　　　　　

　　　　/* 1 */　　　 “Open file error”,　　　　

　　　　/* 2 */　　　 “Failed in sending/receiving a message”,　

　　　　/* 3 */　　　 “Bad arguments”,　

　　　　/* 4 */　　　 “Memeroy is not enough”,

　　　　/* 5 */　　　 “Service is down; try later”,

　　　　/* 6 */　　　 “Unknow information”,

　　　　/* 7 */　　　 “A socket operation has failed”,

　　　　/* 8 */　　　 “Permission denied”,

　　　　/* 9 */　　　 “Bad configuration file format”,　

　　　　/* 10 */　　　“Communication time out”,

　　　　……

　　　　……

　　};

　　

请不要把这个东西放在头文件中，因为如果你的这个头文件被5个函数库（.lib或是.a）所用到，于是他就被链接在这5个.lib或.a中，而如果你的一个程序用到了这5个函数库中的函数，并且这些函数都用到了这个出错信息数组。那么这份信息将有5个副本存在于你的执行文件中。如果你的这个errmsg很大的话，而且你用到的函数库更多的话，你的执行文件也会变得很大。

正确的写法应该把它写到C文件中，然后在各个需要用到errmsg的C文件头上加上 extern char* errmsg[]; 的外部声明，让编译器在链接时才去管他，这样一来，就只会有一个errmsg存在于执行文件中，而且，这样做很利于封装。

我曾遇到过的最疯狂的事，就是在我的目标文件中，这个errmsg一共有112个副本，执行文件有8M左右。当我把errmsg放到C文件中，并为一千多个C文件加上了extern的声明后，所有的函数库文件尺寸都下降了20%左右，而我的执行文件只有5M了。一下子少了3M啊。

〔 备注 〕

—–

有朋友对我说，这个只是一个特例，因为，如果errmsg在执行文件中存在多个副本时，可以加快程序运行速度，理由是errmsg的多个复本会让系统的内存换页降低，达到效率提升。像我们这里所说的errmsg只有一份，当某函数要用errmsg时，如果内存隔得比较远，会产生换页，反而效率不高。

这个说法不无道理，但是一般而言，对于一个比较大的系统，errmsg是比较大的，所以产生副本导致执行文件尺寸变大，不仅增加了系统装载时间，也会让一个程序在内存中占更多的页面。而对于errmsg这样数据，一般来说，在系统运行时不会经常用到，所以还是产生的内存换页也就不算频繁。权衡之下，还是只有一份errmsg的效率高。即便是像logmsg这样频繁使用的的数据，操作系统的内存调度算法会让这样的频繁使用的页面常驻于内存，所以也就不会出现内存换页问题了

11、出错信息的处理

———

你会处理出错信息吗？哦，它并不是简单的输出。看下面的示例：

　　if ( p == NULL ){

　　　　printf ( “ERR: The pointer is NULLn” );

　　}

　　

告别学生时代的编程吧。这种编程很不利于维护和管理，出错信息或是提示信息，应该统一处理，而不是像上面这样，写成一个“硬编码”。第10条对这方面的处理做了一部分说明。如果要管理错误信息，那就要有以下的处理：

　　/* 声明出错代码 */

　　#define　　 ERR_NO_ERROR　　0　/* No error　　　　　　　　 */

　　#define　　 ERR_OPEN_FILE　 1　/* Open file error　　　　　*/

　　#define　　 ERR_SEND_MESG　 2　/* sending a message error　*/

　　#define　　 ERR_BAD_ARGS　　3　/* Bad arguments　　　　　　*/

　　#define　　 ERR_MEM_NONE　　4　/* Memeroy is not enough　　*/

　　#define　　 ERR_SERV_DOWN　 5　/* Service down try later　 */

　　#define　　 ERR_UNKNOW_INFO 6　/* Unknow information　　　 */

　　#define　　 ERR_SOCKET_ERR　7　/* Socket operation failed　*/

　　#define　　 ERR_PERMISSION　8　/* Permission denied　　　　*/

　　#define　　 ERR_BAD_FORMAT　9　/* Bad configuration file　 */

　　#define　　 ERR_TIME_OUT　 10　/* Communication time out　 */

　　

　　/* 声明出错信息 */

　　char* errmsg[] = {

　　　　/* 0 */　　　 “No error”,　　　　　　　　

　　　　/* 1 */　　　 “Open file error”,　　　　

　　　　/* 2 */　　　 “Failed in sending/receiving a message”,　

　　　　/* 3 */　　　 “Bad arguments”,　

　　　　/* 4 */　　　 “Memeroy is not enough”,

　　　　/* 5 */　　　 “Service is down; try later”,

　　　　/* 6 */　　　 “Unknow information”,

　　　　/* 7 */　　　 “A socket operation has failed”,

　　　　/* 8 */　　　 “Permission denied”,

　　　　/* 9 */　　　 “Bad configuration file format”,　

　　　　/* 10 */　　　“Communication time out”,

　　};

　　　　　　　　　　　　　　　

　　/* 声明错误代码全局变量 */

　　long errno = 0;

　　

　　/* 打印出错信息函数 */

　　void perror( char* info)

　　{

　　　　if ( info ){

　　　　　　printf(“%s: %sn”, info, errmsg[errno] );

　　　　　　return;

　　　　}

　　　　

　　　　printf(“Error: %sn”, errmsg[errno] );

　　}

这个基本上是ANSI的错误处理实现细节了，于是当你程序中有错误时你就可以这样处理：

　　bool CheckPermission( char* userName )

　　{

　　　　if ( strcpy(userName, “root”) != 0 ){

　　　　　　errno = ERR_PERMISSION_DENIED;

　　　　　　return (FALSE);

　　　　}

　　　　

　　　　…

　　}

　　

　　main()

　　{

　　　　…

　　　　if (! CheckPermission( username ) ){

　　　　　　perror(“main()”);

　　　　}

　　　　…

　　}

　　　　　　　　　　　　　　　

一个即有共性，也有个性的错误信息处理，这样做有利同种错误出一样的信息，统一用户界面，而不会因为文件打开失败，A程序员出一个信息，B程序员又出一个信息。而且这样做，非常容易维护。代码也易读。

当然，物极必反，也没有必要把所有的输出都放到errmsg中，抽取比较重要的出错信息或是提示信息是其关键，但即使这样，这也包括了大多数的信息。

12、常用函数和循环语句中的被计算量

—————–

看一下下面这个例子：

　　for( i=0; i<1000; i++ ){

　　　　GetLocalHostName( hostname );

　　　　…

　　}

　　

GetLocalHostName的意思是取得当前计算机名，在循环体中，它会被调用1000次啊。这是多么的没有效率的事啊。应该把这个函数拿到循环体外，这样只调用一次，效率得到了很大的提高。虽然，我们的编译器会进行优化，会把循环体内的不变的东西拿到循环外面，但是，你相信所有编译器会知道哪些是不变的吗？我觉得编译器不可靠。最好还是自己动手吧。

同样，对于常用函数中的不变量，如：

GetLocalHostName(char* name)

{

　　char funcName[] = “GetLocalHostName”;

　　

　　sys_log( “%s begin……”, funcName );

　　…

　　sys_log( “%s end……”, funcName );

}

如果这是一个经常调用的函数，每次调用时都要对funcName进行分配内存，这个开销很大啊。把这个变量声明成static吧，当函数再次被调用时，就会省去了分配内存的开销，执行效率也很好。

　　

13、函数名和变量名的命名

————

我看到许多程序对变量名和函数名的取名很草率，特别是变量名，什么a,b,c,aa,bb,cc，还有什么flag1,flag2, cnt1, cnt2，这同样是一种没有“修养”的行为。即便加上好的注释。好的变量名或是函数名，我认为应该有以下的规则：

　　

　　1) 直观并且可以拼读，可望文知意，不必“解码”。

　　2) 名字的长度应该即要最短的长度，也要能最大限度的表达其含义。

　　3) 不要全部大写，也不要全部小写，应该大小写都有，如：GetLocalHostName 或是 UserAccount。

　　4) 可以简写，但简写得要让人明白，如：ErrorCode -> ErrCode,　ServerListener -> ServLisner，UserAccount -> UsrAcct 等。

　　5) 为了避免全局函数和变量名字冲突，可以加上一些前缀，一般以模块简称做为前缀。

　　6) 全局变量统一加一个前缀或是后缀，让人一看到这个变量就知道是全局的。

　　7) 用匈牙利命名法命名函数参数，局部变量。但还是要坚持“望文生意”的原则。

　　8) 与标准库（如：STL）或开发库（如：MFC）的命名风格保持一致。

　　

　　

14、函数的传值和传指针

————

向函数传参数时，一般而言，传入非const的指针时，就表示，在函数中要修改这个指针把指内存中的数据。如果是传值，那么无论在函数内部怎么修改这个值，也影响不到传过来的值，因为传值是只内存拷贝。

什么？你说这个特性你明白了，好吧，让我们看看下面的这个例程：

void

GetVersion(char* pStr)

{

　　pStr = malloc(10);

　　strcpy ( pStr, “2.0” );

}

main()

{

　　char* ver = NULL;

　　GetVersion ( ver );

　　…

　　…

　　free ( ver );

}

我保证，类似这样的问题是一个新手最容易犯的错误。程序中妄图通过函数GetVersion给指针ver分配空间，但这种方法根本没有什么作用，原因就是–这是传值，不是传指针。你或许会和我争论，我分明传的时指针啊？再仔细看看，其实，你传的是指针其实是在传值。

15、修改别人程序的修养

———–

当你维护别人的程序时，请不要非常主观臆断的把已有的程序删除或是修改。我经常看到有的程序员直接在别人的程序上修改表达式或是语句。修改别人的程序时，请不要删除别人的程序，如果你觉得别人的程序有所不妥，请注释掉，然后添加自己的处理程序，必竟，你不可能100%的知道别人的意图，所以为了可以恢复，请不依赖于CVS或是SourceSafe这种版本控制软件，还是要在源码上给别人看到你修改程序的意图和步骤。这是程序维护时，一个有修养的程序员所应该做的。

如下所示，这就是一种比较好的修改方法：

　　/*

　　 * —– commented by haoel 2003/04/12 ——

　　 *

　　 *　 char* p = ( char* ) malloc( 10 );

　　 *　 memset( p, 0, 10 );

　　 */

　　

　　/* —— Added by haoel　 2003/04/12 —– */

　　 char* p = ( char* )calloc( 10, sizeof char );

　　/* —————————————- */

　　…

当然，这种方法是在软件维护时使用的，这样的方法，可以让再维护的人很容易知道以前的代码更改的动作和意图，而且这也是对原作者的一种尊敬。

以“注释 - 添加”方式修改别人的程序，要好于直接删除别人的程序。

16、把相同或近乎相同的代码形成函数和宏

———————

有人说，最好的程序员，就是最喜欢“偷懒”的程序，其中不无道理。

如果你有一些程序的代码片段很相似，或直接就是一样的，请把他们放在一个函数中。而如果这段代码不多，而且会被经常使用，你还想避免函数调用的开销，那么就把他写成宏吧。

千万不要让同一份代码或是功能相似的代码在多个地方存在，不然如果功能一变，你就要修改好几处地方，这种会给维护带来巨大的麻烦，所以，做到“一改百改”，还是要形成函数或是宏。

17、表达式中的括号

———

如果一个比较复杂的表达式中，你并不是很清楚各个操作符的忧先级，即使是你很清楚优先级，也请加上括号，不然，别人或是自己下一次读程序时，一不小心就看走眼理解错了，为了避免这种“误解”，还有让自己的程序更为清淅，还是加上括号吧。

比如，对一个结构的成员取地址：

　　GetUserAge( &( UserInfo->age ) );

虽然，&UserInfo->age中，->操作符的优先级最高，但加上一个括号，会让人一眼就看明白你的代码是什么意思。

再比如，一个很长的条件判断：

if ( ( ch[0] >= &acute;0&acute; || ch[0] <= &acute;9&acute; ) &&

　　 ( ch[1] >= &acute;a&acute; || ch[1] <= &acute;z&acute; ) &&

　　 ( ch[2] >= &acute;A&acute; || ch[2] <= &acute;Z&acute; )　　)

　　

括号，再加上空格和换行，你的代码是不是很容易读懂了？　　

18、函数参数中的const

———–

对于一些函数中的指针参数，如果在函数中只读，请将其用const修饰，这样，别人一读到你的函数接口时，就会知道你的意图是这个参数是[in]，如果没有const时，参数表示[in/out]，注意函数接口中的const使用，利于程序的维护和避免犯一些错误。

虽然，const修饰的指针，如：const char* p，在C中一点用也没有，因为不管你的声明是不是const，指针的内容照样能改，因为编译器会强制转换，但是加上这样一个说明，有利于程序的阅读和编译。因为在C中，修改一个const指针所指向的内存时，会报一个Warning。这会引起程序员的注意。

C++中对const定义的就很严格了，所以C++中要多多的使用const，const的成员函数，const的变量，这样会对让你的代码和你的程序更加完整和易读。（关于C++的const我就不多说了）

19、函数的参数个数（多了请用结构）

—————–

函数的参数个数最好不要太多，一般来说6个左右就可以了，众多的函数参数会让读代码的人一眼看上去就很头昏，而且也不利于维护。如果参数众多，还请使用结构来传递参数。这样做有利于数据的封装和程序的简洁性。

也利于使用函数的人，因为如果你的函数个数很多，比如12个，调用者很容易搞错参数的顺序和个数，而使用结构struct来传递参数，就可以不管参数的顺序。

而且，函数很容易被修改，如果需要给函数增加参数，不需要更改函数接口，只需更改结构体和函数内部处理，而对于调用函数的程序来说，这个动作是透明的。

20、函数的返回类型，不要省略

————–

我看到很多程序写函数时，在函数的返回类型方面不太注意。如果一个函数没有返回值，也请在函数前面加上void的修饰。而有的程序员偷懒，在返回int的函数则什么不修饰（因为如果不修饰，则默认返回int），这种习惯很不好，还是为了原代码的易读性，加上int吧。

所以函数的返回值类型，请不要省略。

另外，对于void的函数，我们往往会忘了return，由于某些C/C++的编译器比较敏感，会报一些警告，所以即使是void的函数，我们在内部最好也要加上return的语句，这有助于代码的编译。

21、goto语句的使用

———

N年前，软件开发的一代宗师–迪杰斯特拉(Dijkstra)说过：“goto statment is harmful !!”，并建议取消goto语句。因为goto语句不利于程序代码的维护性。

这里我也强烈建议不要使用goto语句，除非下面的这种情况：

　　#define FREE(p) if(p) {

　　　　　　　　　　　　free(p);

　　　　　　　　　　　　p = NULL;

　　　　　　　　　　}

　　main()

　　{

　　　　char *fname=NULL, *lname=NULL, *mname=NULL;

　　　　fname = ( char* ) calloc ( 20, sizeof(char) );

　　　　if ( fname == NULL ){

　　　　　　goto ErrHandle;

　　　　}

　　　　lname = ( char* ) calloc ( 20, sizeof(char) );

　　　　if ( lname == NULL ){

　　　　　　goto ErrHandle;

　　　　}

　　　　mname = ( char* ) calloc ( 20, sizeof(char) );

　　　　if ( mname == NULL ){

　　　　　　goto ErrHandle;

　　　　}

　　　　

　　　　……

　　

　　　　

　　 ErrHandle:

　　　　FREE(fname);

　　　　FREE(lname);

　　　　FREE(mname);

　　　　ReportError(ERR_NO_MEMOEY);

　　 }

也只有在这种情况下，goto语句会让你的程序更易读，更容易维护。（在用嵌C来对数据库设置游标操作时，或是对数据库建立链接时，也会遇到这种结构）

22、宏的使用

——

很多程序员不知道C中的“宏”到底是什么意思？特别是当宏有参数的时候，经常把宏和函数混淆。我想在这里我还是先讲讲“宏”，宏只是一种定义，他定义了一个语句块，当程序编译时，编译器首先要执行一个“替换”源程序的动作，把宏引用的地方替换成宏定义的语句块，就像文本文件替换一样。这个动作术语叫“宏的展开”

使用宏是比较“危险”的，因为你不知道宏展开后会是什么一个样子。例如下面这个宏：

　　#define　MAX(a, b)　　 a>b?a:b

当我们这样使用宏时，没有什么问题： MAX( num1, num2 ); 因为宏展开后变成 num1>num2?num1:num2；。但是，如果是这样调用的，MAX( 17+32, 25+21 ); 呢，编译时出现错误，原因是，宏展开后变成：17+32>25+21?17+32:25+21，哇，这是什么啊？

所以，宏在使用时，参数一定要加上括号，上述的那个例子改成如下所示就能解决问题了。

　　#define　MAX( (a), (b) )　　 (a)>(b)?(a):(b)

　　

即使是这样，也不这个宏也还是有Bug，因为如果我这样调用 MAX(i++, j++); ，经过这个宏以后，i和j都被累加了两次，这绝不是我们想要的。

　　

所以，在宏的使用上还是要谨慎考虑，因为宏展开是的结果是很难让人预料的。而且虽然，宏的执行很快（因为没有函数调用的开销），但宏会让源代码澎涨，使目标文件尺寸变大，（如：一个50行的宏，程序中有1000个地方用到，宏展开后会很不得了），相反不能让程序执行得更快（因为执行文件变大，运行时系统换页频繁）。

因此，在决定是用函数，还是用宏时得要小心。

23、static的使用

——–

static关键字，表示了“静态”，一般来说，他会被经常用于变量和函数。一个static的变量，其实就是全局变量，只不过他是有作用域的全局变量。比如一个函数中的static变量：

char*

getConsumerName()

{

　　static int cnt = 0;

　　

　　….

　　cnt++;

　　….

}

cnt变量的值会跟随着函数的调用次而递增，函数退出后，cnt的值还存在，只是cnt只能在函数中才能被访问。而cnt的内存也只会在函数第一次被调用时才会被分配和初始化，以后每次进入函数，都不为static分配了，而直接使用上一次的值。

对于一些被经常调用的函数内的常量，最好也声明成static（参见第12条）

但static的最多的用处却不在这里，其最大的作用的控制访问，在C中如果一个函数或是一个全局变量被声明为static，那么，这个函数和这个全局变量，将只能在这个C文件中被访问，如果别的C文件中调用这个C文件中的函数，或是使用其中的全局（用extern关键字），将会发生链接时错误。这个特性可以用于数据和程序保密。

24、函数中的代码尺寸

———-

一个函数完成一个具体的功能，一般来说，一个函数中的代码最好不要超过600行左右，越少越好，最好的函数一般在100行以内，300行左右的孙函数就差不多了。有证据表明，一个函数中的代码如果超过500行，就会有和别的函数相同或是相近的代码，也就是说，就可以再写另一个函数。

另外，函数一般是完成一个特定的功能，千万忌讳在一个函数中做许多件不同的事。函数的功能越单一越好，一方面有利于函数的易读性，另一方面更有利于代码的维护和重用，功能越单一表示这个函数就越可能给更多的程序提供服务，也就是说共性就越多。

虽然函数的调用会有一定的开销，但比起软件后期维护来说，增加一些运行时的开销而换来更好的可维护性和代码重用性，是很值得的一件事。

25、typedef的使用

———

typedef是一个给类型起别名的关键字。不要小看了它，它对于你代码的维护会有很好的作用。比如C中没有bool，于是在一个软件中，一些程序员使用int，一些程序员使用short，会比较混乱，最好就是用一个typedef来定义，如：

　　typedef char bool;

　　

一般来说，一个C的工程中一定要做一些这方面的工作，因为你会涉及到跨平台，不同的平台会有不同的字长，所以利用预编译和typedef可以让你最有效的维护你的代码，如下所示：

　　#ifdef SOLARIS2_5

　　　typedef boolean_t　　 BOOL_T;

　　#else

　　　typedef int　　　　　 BOOL_T;

　　#endif

　　

　　typedef short　　　　　 INT16_T;

　　typedef unsigned short　UINT16_T;

　　typedef int　　　　　　 INT32_T;

　　typedef unsigned int　　UINT32_T;

　　

　　#ifdef WIN32

　　　typedef _int64　　　　INT64_T;

　　#else

　　　typedef long long　　 INT64_T;

　　#endif

　　

　　typedef float　　　　　 FLOAT32_T;

　　typedef char*　　　　　 STRING_T;

　　typedef unsigned char　 BYTE_T;

　　typedef time_t　　　　　TIME_T;

　　typedef INT32_T　　　　 PID_T;

　　

使用typedef的其它规范是，在结构和函数指针时，也最好用typedef，这也有利于程序的易读和可维护性。如：

　　typedef struct _hostinfo {

　　　　HOSTID_T　 host;

　　　　INT32_T　　hostId;

　　　　STRING_T　 hostType;

　　　　STRING_T　 hostModel;

　　　　FLOAT32_T　cpuFactor;

　　　　INT32_T　　numCPUs;

　　　　INT32_T　　nDisks;

　　　　INT32_T　　memory;

　　　　INT32_T　　swap;

　　} HostInfo;

　　typedef INT32_T (*RsrcReqHandler)(

　　 void *info,

　　 JobArray *jobs,

　　 AllocInfo *allocInfo,

　　 AllocList *allocList);

C++中这样也是很让人易读的：

　　typedef CArray<HostInfo, HostInfo&> HostInfoArray;

于是，当我们用其定义变量时，会显得十分易读。如：

　　HostInfo* phinfo;

　　RsrcReqHandler* pRsrcHand;

这种方式的易读性，在函数的参数中十分明显。

关键是在程序种使用typedef后，几乎所有的程序中的类型声明都显得那么简洁和清淅，而且易于维护，这才是typedef的关键。

26、为常量声明宏

——–

最好不要在程序中出现数字式的“硬编码”，如：

　　int user[120];

　　

为这个120声明一个宏吧。为所有出现在程序中的这样的常量都声明一个宏吧。比如TimeOut的时间，最大的用户数量，还有其它，只要是常量就应该声明成宏。如果，突然在程序中出现下面一段代码，

　　for ( i=0; i<120; i++){

　　　　….

　　}

120是什么？为什么会是120？这种“硬编码”不仅让程序很读，而且也让程序很不好维护，如果要改变这个数字，得同时对所有程序中这个120都要做修改，这对修改程序的人来说是一个很大的痛苦。所以还是把常量声明成宏，这样，一改百改，而且也很利于程序阅读。

　　#define MAX_USR_CNT 120

　　

　　for ( i=0; i<MAX_USER_CNT; i++){

　　　　….

　　}

这样就很容易了解这段程序的意图了。

有的程序员喜欢为这种变量声明全局变量，其实，全局变量应该尽量的少用，全局变量不利于封装，也不利于维护，而且对程序执行空间有一定的开销，一不小心就造成系统换页，造成程序执行速度效率等问题。所以声明成宏，即可以免去全局变量的开销，也会有速度上的优势。

27、不要为宏定义加分号

———–

有许多程序员不知道在宏定义时是否要加分号，有时，他们以为宏是一条语句，应该要加分号，这就错了。当你知道了宏的原理，你会赞同我为会么不要为宏定义加分号的。看一个例子：

　　#define MAXNUM 1024;

这是一个有分号的宏，如果我们这样使用：

　　half = MAXNUM/2;

　　

　　if ( num < MAXNUM )

等等，都会造成程序的编译错误，因为，当宏展开后，他会是这个样子的：

　　half = 1024;/2;

　　

　　if ( num < 1024; )

　　

是的，分号也被展进去了，所以造成了程序的错误。请相信我，有时候，一个分号会让你的程序出现成百个错误。所以还是不要为宏加最后一个分号，哪怕是这样：

　　#define LINE　　“=================================”

　　

　　#define PRINT_LINE　printf(LINE)

　　#define PRINT_NLINE(n)　while ( n– >0 ) { PRINT_LINE; }

　　

都不要在最后加上分号，当我们在程序中使用时，为之加上分号，

　　main()

　　{

　　　　char *p = LINE;

　　　　PRINT_LINE;

　　}

这一点非常符合习惯，而且，如果忘加了分号，编译器给出的错误提示，也会让我们很容易看懂的。

28、||和&&的语句执行顺序

————

条件语句中的这两个“与”和“或”操作符一定要小心，它们的表现可能和你想像的不一样，这里条件语句中的有些行为需要和说一下：

　　express1 || express2

　　　　

　　先执行表达式express1如果为“真”，express2将不被执行，express2仅在express1为“假”时才被执行。因为第一个表达式为真了，整个表达式都为真，所以没有必要再去执行第二个表达式了。

　　express1 && express2

　　先执行表达式express1如果为“假”，express2将不被执行，express2仅在express1为“真”时才被执行。因为第一个表达式为假了，整个表达式都为假了，所以没有必要再去执行第二个表达式了。

于是，他并不是你所想像的所有的表达式都会去执行，这点一定要明白，不然你的程序会出现一些莫明的运行时错误。

例如，下面的程序：

　　if ( sum > 100 &&

　　　　 ( ( fp=fopen( filename,”a” ) ) != NULL )　 {

　　　　

　　　　 fprintf(fp, “Warring: it beyond one hundredn”);

　　　　 ……

　　}

　　

　　fprintf( fp, “ sum is %id n”, sum );

　　fclose( fp );

本来的意图是，如果sum > 100 ，向文件中写一条出错信息，为了方便，把两个条件判断写在一起，于是，如果sum<=100时，打开文件的操作将不会做，最后，fprintf和fclose就会发现未知的结果。

再比如，如果我想判断一个字符是不是有内容，我得判断这个字符串指针是不为空（NULL）并且其内容不能为空（Empty），一个是空指针，一个是空内容。我也许会这样写：

　　if ( ( p != NULL ) && ( strlen(p) != 0 ))

于是，如果p为NULL，那么strlen(p)就不会被执行，于是，strlen也就不会因为一个空指针而“非法操作”或是一个“Core Dump”了。

记住一点，条件语句中，并非所有的语句都会执行，当你的条件语句非常多时，这点要尤其注意。

29、尽量用for而不是while做循环

—————

基本上来说，for可以完成while的功能，我是建议尽量使用for语句，而不要使用while语句，特别是当循环体很大时，for的优点一下就体现出来了。

因为在for中，循环的初始、结束条件、循环的推进，都在一起，一眼看上去就知道这是一个什么样的循环。刚出学校的程序一般对于链接喜欢这样来：

　　p = pHead;

　　

　　while ( p ){

　　　　…

　　　　…

　　　　p = p->next;

　　}

当while的语句块变大后，你的程序将很难读，用for就好得多：

　　for ( p=pHead;　p; p=p->next ){

　　..

　　}

一眼就知道这个循环的开始条件，结束条件，和循环的推进。大约就能明白这个循环要做个什么事？而且，程序维护进来很容易，不必像while一样，在一个编辑器中上上下下的捣腾。

30、请sizeof类型而不是变量

————-

许多程序员在使用sizeof中，喜欢sizeof变量名，例如：

int score[100];

char filename[20];

struct UserInfo usr[100];

在sizeof这三个的变量名时，都会返回正确的结果，于是许多程序员就开始sizeof变量名。这个习惯很虽然没有什么不好，但我还是建议sizeof类型。

我看到过这个的程序：

　　pScore = (int*) malloc( SUBJECT_CNT );

　　memset( pScore, 0, sizeof(pScore) );

　　…

　　

此时，sizeof(pScore)返回的就是4（指针的长度），不会是整个数组，于是，memset就不能对这块内存进行初始化。为了程序的易读和易维护，我强烈建议使用类型而不是变量，如：

对于score：　　 sizeof(int) * 100　 /* 100个int */

对于filename：　sizeof(char) * 20　 /* 20个char */

对于usr：　　　 sizeof(struct UserInfo) * 100　 /* 100个UserInfo */

这样的代码是不是很易读？一眼看上去就知道什么意思了。

另外一点，sizeof一般用于分配内存，这个特性特别在多维数组时，就能体现出其优点了。如，给一个字符串数组分配内存，

/*

• 分配一个有20个字符串，
  

• 每个字符串长100的内存
  

*/

char* *p;

/*

• 错误的分配方法
  

*/

p = (char**)calloc( 20*100, sizeof(char) );

/*

• 正确的分配方法
  

*/

p = (char**) calloc ( 20, sizeof(char*) );

for ( i=0; i<20; i++){

　　/p = (char) calloc ( 100, sizeof(char) );*/

　　p = (char*) calloc ( 100, sizeof(char) );

}

（注：上述语句被注释掉的是原来的，是错误的，由dasherest朋友指正，谢谢）

为了代码的易读，省去了一些判断，请注意这两种分配的方法，有本质上的差别。

31、不要忽略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了）

　　

不管怎么说，编译器的Warning不要小视，最好不要忽略，一个程序都做得出来，何况几个小小的Warning呢？

32、书写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语言全部被替换成了空。一举两得，一箭双雕，何乐而不为呢？

顺便提一下，两个很有用的系统宏，一个是“FILE”，一个是“LINE”，分别表示，所在的源文件和行号，当你调试信息或是输出错误时，可以使用这两个宏，让你一眼就能看出你的错误，出现在哪个文件的第几行中。这对于用C/C++做的大工程非常的管用。

综上所述32条，都是为了三大目的–

　　1、程序代码的易读性。

　　2、程序代码的可维护性，

　　3、程序代码的稳定可靠性。

　　

有修养的程序员，就应该要学会写出这样的代码！这是任何一个想做编程高手所必需面对的细小的问题，编程高手不仅技术要强，基础要好，而且最重要的是要有“修养”！

好的软件产品绝不仅仅是技术，而更多的是整个软件的易维护和可靠性。　　

软件的维护有大量的工作量花在代码的维护上，软件的Upgrade，也有大量的工作花在代码的组织上，所以好的代码，清淅的，易读的代码，将给大大减少软件的维护和升级成本。

电视《雍正王朝》讲了这么一个故事：大将军年羹尧奉命到青海平叛，清军因路途遥远，军耗巨大，因此力求速战速决。但叛军避开锋芒，东躲西藏，年羹尧没有办法找到叛军决战。这时，朝廷内外压力越来越大，年羹尧陷入困境。这是一位谋士对年说：我知道叛军在那里。年大喜。这位谋士指出，敌人就在不远处的一座皇封寺庙里。年不信，谋士不慌不忙地说：这就是灯下黑，离自己越近就越不可能意识到，但却是最可能的地方。果然，大军一出，大获全胜。

我想讲一些关于程序员对自身认识的故事，这些故事都和灯下黑有关。只要正确认识自己，道理非常简单，但是，到处都可以看到灯下黑的故事。

某程序员，有一天接到一个任务：公司的有一个产品的文件太大了，要求采用压缩算法，减少尺寸，最好能压缩20%。

程序员兴高采烈地接受了任务：以前没玩过压缩算法，这下可以学习新东西了！研究了几个月后，他觉得差不多了，就交给了项目经理。项目经理正等着呢，高兴坏了，拿着演示文件就去找产品经理。产品经理开始挺高兴，看完脸就拉下来了。打开文件，把所有的文件尺寸一算，很淡淡的说：“才压缩了10%，有什么用啊！”

程序员愣住了，“不会吧！我看过的，压缩了 20%！”

产品经理指着文件列表说：“你看，某文件是压缩了20%，可你的压缩算法增加了一个动态库文件，尺寸还不小，总共加起来，不就只减少了10%吗？”


各位看官，这是不是软件公司里经常发生的情形？

这种失败的成因当然是复杂的，有沟通管理方面的问题，也有程序员能力的问题。我今天想要说的是程序员认识方面的问题。

继续故事：

项目经理很没面子，回去就和程序员找原因。项目经理是老程序员了，直话直说；终于弄清楚的事情的本质：

第一，这位程序员一个的时间读了很多关于压缩算法的书，会了不少算法。可是从来没比较过算法的优劣。这老兄觉得研究算法很有趣，乐此不彼，写了好几个实现。

第二，这位老兄在最后几天才想起来20%的目标，也没太放在心上，看看差不多就拿出来了。


这是典型的程序员的认识问题，重知识而轻技术。

先从是么是知识，什么是技术说起。

知识就是知道，你知道了某件事是怎么回事，就是有了知识。

技术就是你能做出来，做得好叫技术好，做的不好叫技术差。

怎么写操作系统？看完操作系统原理，再苦读完源代码，这叫有知识了。如果有本事把任务调度、内存管理、IO什么的都写出来，还能写得稳定，快速，可扩展，那是有技术。有知识和有技术可差远了。早年我在工厂实习，要挫一个圆孔，拿着内锉刀干了一天，只挫了一个椭圆；师父来了，三分钟，比冲床冲出来还圆！我是个好学徒，使用锉刀的知识全记住的，可以写一篇内圆挫使用大全。知识是有了，可没这个技术。

程序员也一样。什么C++，Java，.net，什么STL，Struts，Spring，就是门门都满分，这也就是有知识。算不算技术好呢？差远了。软件工程师界就专门出这种不会写程序的“高手”。我遇到一位老兄，精通Java知识，从虚拟机到各类框架，概念，无所不同，谈起Java来，没人说的过他。可是他的代码永远Bug最多，而且都是最简单的Bug，什么逻辑不对啊，功能没实现啊，UI不对啊。他的领导只有又好气又好笑。问下去，发现这老兄写了几个程序文件以后，就不感兴趣了，因为所用的技术没什么不知道的了。所以马马虎虎交差。

说到底，写程序是个手艺活，就和古代的匠人一样，是要讲工艺的。比如一个玉匠，能打造栩栩如生的玉孔雀，那得打的好！要是一个玉匠说，这些手艺我都知道了，重复做东西没劲，将就着给客人做出来吧！那他还不吃西北风！

可是，十几年来，程序员界有的是这样的人，还引发大规模争论。象什么C++和Java之争啦，J2EE和.Net之争啦。你看里边的帖子，不停有人赌这个阵营那个阵营，有发誓一辈子做C++的，有发誓打倒.Net。我还奇怪了，专门没人效忠机器码的，那不是最难最有“学问”吗？这都是在争论什么知识最重要。可是啊，很少有人谈谈怎么做好产品的。


现在程序员最大的问题就是太看重知识，拼命追逐新玩意，而忽略了身边的够得着东西。好，什么C++，Window API都知道了，东西也弄出来了，可是三天两头崩溃，还找不到原因？为什么？有没有看看代码，看看是不是某函数写了2000行，自己都看不懂？是不是全局变量乱用？是不是没考虑前后兼容性？没考虑冗余和故障恢复？

末了再回到开头的故事：

项目经理回去和程序员再重新设计，又多花了一个月，终于达到了目标。但因为这个部分是一个大项目的一部分，整个项目不得不延迟了一个月。

年底考评的时候，项目经理给程序员打了一个及格；程序员不服，告到总经理那里。总经理说：“你知足吧，给你打及格已经看在你干的很辛苦的份上了，因为你没有按时完成，整个项目延迟了一个月，这帐都没找你算呢。”程序员颓然。

点击访问此系列文章

由于本人有很好的C++基础,所以想从C++直接转到C#.

 

1.       布尔值：在C++中，bool类型实质上是一个整数。在C#中，不存在bool类型与其他类型之间的相互转换。

bool 关键字是System.Boolean的别名.它用于声明变量来存储布尔值true和false.

可将布尔值赋给bool变量.也可以将计算为bool类型的表达式赋给bool变量.

在C++中,bool类型的值可转换为int类型的值;也就是说,false等效于零值,而true等效于非零值.在C#中,不存在bool类型与其它类型之间的相互转换.例如,下列if语句在C#中是非法的,而在C++中则是合法的：

int x = 123;

if (x) // 在C# 是错误的

{ printf("The value of x is nonzero."); }

若要测试int类型的变量，必须将该变量与一个值（比如零）进行显式比较，如下所示：

int x = 123;

if (x != 0) // 在C# 中容许

{ printf(“The value of x is nonzero.”); }

2.       long类型：long类型在C#中为64位，而在C++中为32位。

long关键字表示一种整形，该类型根据下表显示的大小和范围存储值。

long取值范围-9223372036854775808到9223372036854775807,在long类型中使用后缀L：

long long2 = 4294967296L;

当使用后缀L时，将根据整数的大小确定它的类型为long还是ulong。

3.       switch语句：与C++中的switch语句不同，C#不支持从一个case标签贯穿到另一个case标签。

switch语句是一个控制语句，它通过将控制传递给其体内的一个case语句来处理多个选择和枚举。

空case标签可以从一个case标签贯穿到另一个：

using System;

class SwitchTest

{

        static void Main()

        {

               int n = 2;

               switch(n)

               {

                      case 1:

                      case 2:
                      case 3:

                             Console.WriteLine(“It`s 1, 2, or 3.”);
                             break;

               default:

                      Console.WriteLine(“Not sure what it is.”);

                      break;

               }

        }

}

OUT: It`s 1, 2, or 3.

4.       委托:C#中的委托大致类似于C++中的函数指针,是类型安全可靠的.

委托类型声明的格式如下:

public delegate void TestDelegate(string message);

delegate关键用于声明一个引用类型,该引用类型可用于封装命名方法或匿名方法.委托类似于C++中的函数指针;但是,委托是类型安全和可靠的.

5.       extern关键字：在C++中，extern用于导入类型。在C#中，extern用于为使用同一程序集的不同版本创建别名。

extern修饰符用于声明在外部实现的方法。extern修饰符的觉用法是在使用Interop服务调入非托管代码DllImport属性一起使用；在这种情况下，该方法还必须声明为static，如下面的所示：

[DllImport(“avifil32.dll”)]

private static extern void AVIFileInit();

将abstract和extern修饰符一起使用来修改同一成员是错误的。使用extern修饰符意味着方法在C#代码的外部实现，而使用abstract外包符意思着在类在未提供方法实现。

6.       static关键字：在C++中，static既可用于声明类级实体，也可用于声明特定于某模块的类型。在C#中，static仅用于声明类级实体。

使用static修饰符声明属于类型本身而不是属于特定对象的静态成员。static修饰符可用于类、字段、方法属性、运算符、事件和构造函数，但不能用于索引器、析构函数或类以外的类型。

备注：

l          常数或者类型声明隐式地静态成员。

l          不能通过实例引用静态成员。然而，可以通过类型名称引用它。

l          尽管类的实例包含该类所有实例字段的单独副本，但每个静态字段只有一个副本。

l          不可以使用this来引用静态方法或属性访问器。

l          如果对类应用static关键字，则该类的所有成员都必须是静态的。

l          类（包括静态类）可以有静态构造函数。在程序开始和实例化类之间的某个时刻调用静态构造函数。

7.       C#中的Main方法和C++中的main函数的声明方式不同。在C#中，它是大写的，并且始终是static的。此外，在C#中，对处理命令行参数的支持要可靠得多。

Main方法是程序的入口点，您将在那里创建对象和调用其他方法。一个C#程序中只能有一个入口点。

class TestClass

{

    static void Main(string[] args)

    {

        // Display the number of command line arguments:

        System.Console.WriteLine(args.Length);

    }

}

概述：

l          Main方法是程序的入口点，程序控制在该方法中开始和结束。

l          该方法在类或结构的内部声明。它必须为静态方法，而不应该为公共方法。

l          它可以具有void或int返回类型。

l          声明Main方法时既可以使用参数，也可以不使用参数。

l          参数可以作为从零开始索引的命令行参数来读取。

l          与C和C++不同，程序的名称不会被当作第一个命令参数。

8.       在C#中，只有在unsafe模式下才允许使用指针。

unsafe关键字表示不安全上下文，该上下文是任何涉及指针的操作所必需的。
可以在类型或成员的声明中使用unsafe修饰符。因此，类型或成员的整个正文范围均被视为不安全上下文。若要编译不安全代码，必须指定/unsafe编译器选项。无法通过公共语言运行库验证不安全代码。

9.       foreach关键字使您可以循环访问数组和集合。

foreach语句为数组或对象集合中的每个元素重复一个嵌入语句级。foreach语句用于循环访问集合以获取所需信息，但不应用于更改集合内容以避免产生不可预知的副作用。

备注：

嵌入语句为数组或集合中的每个元素继续执行。当为集合中的所有元素完成有迭代后，控制传递给foreach块之后的下一个语句。

在此示例中，使用foreach显示整数数组的内容。

// cs_foreach.cs

class ForEachTest

{

        static void Main(string[] args)

        {

               int[] fibarray = new int[] {0, 1, 2, 3, 5, 6, 18};

               foreach(int i in fibarray)

               {

                      System.Console.WriteLine(i);

                     }

       }

}

       输出

0 1 2 3 5 6 18

10.    方法隐藏：C++通过继承支持方法的隐式“隐藏”。在C#中，必须使用new修饰符来显式隐藏继承的成员。

在C#中，new关键字可用作运算符、修饰符或约束。

l          new运算符：用于创建对象和调用构造函数。

new运算符还用于调用值类型的默认构造函数。

不能重载new运算符。如果new运算符分配内在失败，将引发异常OutOfMemoryException。

l          new修饰符：用于向基类成员隐藏继承成员。

在用作修饰符时，new关键字可以显式隐藏从基类继承的成员。隐藏继承的成员意味着该成员的派生版本将替换基类版本。在不使用new修饰符的情况下隐藏成员是允许的，但会生成警告。使用new显式隐藏成员会取消此警告，并记录代之派生版本这一事实。

若要隐藏继承的成员，请使用相同名称在派生类中声明该成员，并使用new修饰符该成员。例如：

public class BaseC

{

        public int x;

        public void invoke(){}

}

public class DerivedC : BaseC

{

        new public void Invoke(){}

}

在此示例中，DerivedC.Invoke隐藏了BaseC.Invoke。字段x不受影响，因为它没有被类似的名称的字段隐藏。

通过继承隐藏名称采用下列形式之一：

1.       引入类或结构中的常数、指定、属性或类型隐藏具有相同名称的所有基类成员。

2.       引入类或结构中的索引器将隐藏具有相同名称的所有基类索引器。

3.       引入类或结构的方法隐藏基类中具有相同名称的属性、字段和类型。同时也隐藏具有相同签名的所有基类方法。

对同一成员同时使用new和override是错误的，因为这两个修饰符在含义上相互排斥。使用new会用同样的名称创建一个新成员并使原始成员变为隐藏的，而override则扩展继承成员的实现。

l          new约束：用于在泛型声明中约束可能用作类型参数的参数的类型。

new结束指定泛型类声明中的任何类型参数都必须有公共的无参数构造函数。当泛型创建类型的新实例时，将此约束应用于类型参数，如下面的示例所示：

class ItemFactory<T> where T: new()

{

public T GetNewItem()

{

return new T();

}

}

当与其他约束一起使用时，new()约束必须最后指定：

using System;

public class ItemFactory<T>

where T: IComparable, new()

{}

这个事件时间很长了,但是还想转下,同时提供一种现在还能用的访问方法.
以下内容转载与博客园和本人无关.

今天，忽然听说维基百科被封了，令我感到非常震惊，赶忙输入维基百科的网址zh.wikipedia.org看看，正如预料的一样，的确是上不去了。

　　维基百科是我经常去的地方，对于我来说，维基百科是一个名副其实的百科全书，我有什么不明白的东西，或者典故，我用GOOGLE搜索时候，显示的第一个条目常常是维基百科的条目。我想，在绝大多数人的心中，维基百科都是一个庞大的网上图书馆。我也对无数义务维护维基百科全书的工作者表示敬意。

　　然而，这么优秀的而庞大的知识宝库，现在竟然不让我们访问，这是我怎么也不曾预料到的。我们国家的治国之道的确大有问题。以前记得电视上有句话，叫做“知识改变命运”。现在我明白了，某些特殊材料制成的人是不希望这个社会上有太多的人拥有知识，人民拥有越多的知识，他就越害怕，中国五千年来一直“民智未开”也不就奇怪了。于是这个对于我们来说是无价之宝的百科全书，自然难免会遭此毒手。

　　一个开明的君主，会顺应历史潮流，体察民情，爱护百姓，树立了政权的良好形象和声誉，赢得了百姓的拥护。在科学技术上，暂时的落后也并不可怕，只要励精图治、奋起直追，努力学习和领会强国的先进经验，那么就会象日本明治维新一样，三十年就能创造一个强盛的国家，成为亚洲强国。

　　而一个无道的昏君则恰好相反，朝中是奸臣当道，君王视其臣民为奴役，实行愚民政策，不思进取，权力不受控制，滥用职权而不顾后果，逆天而行，防民之口，甚于防川，这样的君主岂有不亡之理。

　　孔子有句古话：“民可使由之，不可使知之。” 其意是说：“对于老百姓，只能使他们按照我们的意志去做，不能使他们懂得为什么要这样做。” 国之决策，庶民无从知晓，民间的各种猜忌、揣摩，正是乱世之根也。国家遇到危难，国民亦不知国家之对策，全民岂不如同“一盘散沙”？可叹啊，可叹我中华气数已尽，竟然要亡在一帮无耻的败家子手里。

　　附录：什么是“维基百科”

　　维基百科是一个自由、免费、内容开放的百科全书协作计划，参与者来自世界各地。

　　维基百科本身有三个引人注意的特点。正是这些特点使维基百科与传统的百科全书有所区别：

　　首先，维基百科始终就将自己定位为一个包含人类所有知识领域的百科全书，而不是一本词典，在线的论坛或其他任何东西。

　　其次，计划也是一个wiki，这允许了大众的广泛参与。维基百科是第一个使用wiki系统进行百科全书编撰工作的协作计划。

　　还有一个重要的特点，那就是维基百科是一部内容开放的百科全书。内容开放的材料允许任何第三方不受限制地复制、修改及再发布材料的任何部分或全部。维基百科使用GNU自由文档协定证书。

　　最早将全世界的知识收集于一个屋顶下，供人查阅的要数古代亚历山大图书馆。而出版百科全书的的想法则可以追溯到狄德多等18世纪百科全书派。在各国的大学中，图书馆是最佳的百科全书会集点。今天最常见百科全书的包括了英语的《大不列颠百科全书》、《美国哥伦比亚百科全书》，以及中文的《中国大百科全书》等。

　　利用国际因特网来编写一部免费的百科全书的构想在二十世纪九十年代初就被提出。

　　内容开放运动

　　作为百科全书，维基百科的内容性质与那套著名的《大英百科全书》没什么区别。但是，它的撰写者和管理者却不是能够入选《大英百科全书》作者名单那样的专家，而都是网络志愿者。或许正因为它避开了传统百科全书的精英参与、审阅、论证这个繁琐过程，任何注册者都有资格修改这个百科全书中的任何一个条目，这让它成为了世界上最大的百科全书。

　　随着人类信息传播途径日益畅通，知识过度保护还%

今日整理硬盘无意发现刚学windows编程时写的一段代码,用于在windows下异步读写硬盘用的.
可能网上已经有类似的代码了,小弟在发一次,希望别有人用这做坏事.
打开硬盘有两个东西要知道,第一打开的文件名:\\\\.\\PHYSICALDRIVE0, 0代表第一块硬盘,依次1代表第二块硬盘...第二打开硬盘使用的参数OPEN_EXISTING是不可少的,至于为什么查MSDN.
先把代码发上来大家看看,读写速度还可以几秒就1G了,有空改成完成端口不知道会不会快点.
(注意以下代码不要用\\\\.\\PHYSICALDRIVE0试验,会把硬盘时的第一个G内容写成0,后果可想而知)

    GDI+绘制图片时是可以设置绘图清晰度的，清晰绘制比较占系统资源，普通模式绘制速度比较快，这个靠自己权衡了。今天在以前做的一个缩略图生成函数里加了GDI+清晰度设置的代码。
    其实设置清晰度很简单，只要加上一下三行代码，就可以让生成的缩略图和PhotoShop生成的效果一样了:

完整的缩略图生成函数是这样的:

前段时间做了一个图片透明画的代码，基本思路是使用ColorMatrix设置位图的Alpha通道，使其透明化。这类代码可能高手都懒得写，像我等菜鸟要用时就得费一番周则研究了，所以我把做完的代码发上来，大家有需要用的就拿去用，如果高兴的话还可以评论里说声加油之类的话，呵呵。

利用ColorMatrix还可以调整整个位图的RGB值，看各位需要发挥了。

代码如下：

VS1.4挤房+MH的登陆器.rar
把文件解压到VS1.4里,运行VSClinet_MH.exe
郁闷在今天VS网通的房间变成5个了.


MapHack在这下载http://www.ayssss.cn/

失眠是一件非常复杂的事，有许多原因会形成失眠，不同的原因会有不同的失眠状况，也必需不同的对治方法。

当身体处於肺热状态时，嘴唇发红，必定失眠。这种失眠，只要喝喝薑茶，让身体顺利的排除寒气，肺热状态消失了，就能睡。

当身体处於心火盛、肝火盛时也会出现肺热的现象，这时就需要先泄除心火和肝火。

我们由意志所设定的的睡眠时间和身体的睡眠时间衝突，也会形成失眠．这种失眠是最普遍的一种。
身体在中午时想小睡一会，可是我们把这个”坏”习惯戒除了；到了傍晚时又累了，我们再用意志力克服它；晚上八九点又睏了，我们忙著做杂事没时间睡。
这几次用意志力对抗身体，身体只好產生肝火，提供透支的体力能源，满足我们意志上的要求。
等一切忙完，我们终於可以入睡了，但身体火烧得正旺呢，祂不想睡，於是失眠了。
身体想睡，你不让睡，等你想睡时，祂已经不想睡了。

对治这种失眠最好的方法，是放任身体自然的睡，想睡就睡，不想睡就不要睡，大约两周后，应该就能正常。
但这种听身体声音的方法并不是那麼容易，我们的意志力已经控制身体很久了，不习惯也不会听身体的声音。

饮食也可以用一样的方法，找出身体想吃的东西。
同样的我们已经很久都用自己的意志吃东西，很少听听祂想吃什麼。
在这个医学还没有真正明白身体的时代，利用现代医学的知识吃，远比相信自己身体的智慧吃来得愚蠢得多。
现代医学最大的问题就是高估了他们的知识，低估了人体的智慧。

另外，心事造成的失眠，除了解决了心事，无药也无法可治．只有靠安眠药一途。

如果你相信疾病是一种业力，那麼应该明白不会有药物或医生能单方面治好你的病，医生只能帮你找出原因，告诉你方向，剩下的都必需自己努力去克服问题，真正造成治病效果的必定是你自己努力的部份。业力只有透过自己努力，做了某些习性上的改变才会去除。

 

最近听说在中国大陆有人提议废除中医，而且还是科学界的人提出来，并且有不少人附和，经常有人问我这方面的意见。我认為在所有慢性病都还没有找到解决方案的今天，对於中医和西医做出评价都是很不智的。这些争论并不会使医学有丝毫进展，不可能从这些争议中发展出任何慢性病的治疗技术，实在没有太大的意义。

西医在细菌学方面的发展，克服了大多数的传染病，无疑的為人类做出极大的贡献，而这方面知识和技术的应用，也将长期继续為人类服务，是中医完全无法替代的。

另外，西医在外科手术方面的长足发展，以及在急救技术上的各种手段，无疑的也是中医无法也不需要替代的。

虽然西医佔据了今天主流医学的地位，从医院的外观看来西医似乎非常进步。但是仔细检验医学的成果，所有慢性病的病因今天还没有一个被理清楚，也没有发展出任何一个慢性病确实痊癒的治疗技术。从结果看来，医学还在发展阶段，离成熟阶段还有很长远的距离。说得更白一点，还在寻找发展方向的阶段。

在慢性病的治疗方面，虽然中医也不具备已经成熟的痊癒技术。但是相较于西医，中医有更完整的理论基础，也有更大的机会发展出解决方案。这些都是仍在发展中的技术，在没有完全证实成功或失败之前，没有必要在这个时候决定中医的去留。

另外，对於『迷信』或『不科学』的判定，在不同时代会有不同的标準。大多数认定中医是迷信或不科学的人，其假设是现代的科技已达到非常发达的年代，这是每一个年代都有人会犯的错误。

从现在的观点评论一百年前的科技，没有人会认為一百年前科技很发达。同理，一百年后我们的子孙，也必定没有人会认定我们今天的科技很发达。现代不能被科学认证的理论，很可能在一百年或五百年后的科技手段就能被认证。在人类歷史上的五百年甚至一千年，转眼即逝。不能被现代科学认证的理论，有可能是迷信，也有可能是现代科技还不具备足够的证实能力。

根据西方国家的估计，今天的科技成份，大约有95%是过去五十年发展出来的。从这个观点，相较於今天的科技水準，可以说五十年前科技还在萌芽期。也许到了五十年后，人们还是会发现当时的科技成份有95%是接下来五十年发展出来的。从当时往回看，今天的科技仍在萌芽期。就人类歷史而言，五十年不过是很短的瞬间，可以说从今天往前或往后一百年之内，都在科技的萌芽期，今天的科技仍处於非常原始的阶段。

以我们今天经常使用的汽车為例，今天最好的汽车，其燃烧效率大约在20%上下，大约有80%的能源都成為污染空气的废气，和提升地球温度的废热。一部小轿车大约有一千公斤，大多数情形车上只运载一个不到一百公斤的人，也就是不到十分之一的能量是最终用来载人，两个数位相乘真正用来运人的能源效率只有2%。从这些数字上看，汽车实在是非常原始的交通工具。

十六世纪，哥白尼发表了地圆说，被当时的主流科学家严厉批评，哥白尼还因此送了命。当时的主流科学家，即立足於当时的科技已经非常进步的假设基础所做出的结论。歷史上这种错误总在不断的重演，难保今天提议废除中医的这些科学家们，不会和当年批评哥白尼的主流科学家犯了相同的错误。

西方国家有感于循著西医的方向似乎找不到慢性病的解决方案，近几年纷纷成立了中医的研究中心，试著从中医的理论中扩展他们的思路。在这个时候中国正在讨论是不是要废除中医是非常讽刺的。

生气发作了伤肝，隐忍了伤脾胃，忽略了伤大肠，血气太低时还会造成致命的肺积水。似乎只要怒气產生了，就无从避免对身体的伤害。可是人总有七情六欲，不可能不生气。最好我们能瞭解自己生气的模式，就能找出减少生气伤害的方法。
想像我们的胸中有许多怒气的小瓶子，每一个瓶子对应著我们周围的一个人。当我们对这个人有什麼不满意，可是又不好意思明说时，就把这点不满意放进了对应这个人的瓶子里。今天放一点，明天又放一点，有一天瓶子放满了，又出现了一件小事让你不满，可是瓶子已经满了。这时你的情绪已经到了『忍无可忍』的地步，於是怒气就发作了。这时不是只把最后的那点不满发作出来，而是把长期点点滴滴放进瓶子里的怒气，一鼓脑的全倒了出来。对方这时常常会出现一脸的茫茫然，心里嘀咕著：『又没什麼大不了的事，以前这种事又不是没出现过，怎麼生这麼大的气』。我们自己则常常在脾气发作到一半时，已经不记得今天生气的真正原因，只觉得这个人太可恶了，事后也常常想不起来那天是什麼事惹你生那麼大的气。
这是大多数人生气的模式，多数情形怒气的发作都是这种『零存整付』的模式。中国人的儒家思想，教导人们温、良、恭、俭、让的美德，忍让成為美德的一种。人和人相处，总会发生摩擦，大多数的中国人从小就被教导要把许多小的不满隐藏起来，『这怎麼好意思说，算了！』是许多人经常在心里嘀咕的。
其实许多小不满，只要适当的沟通，最多小吵两句，就能化解。这种小吵的争执，对肝的伤害会比真正生很大的气小得多。充份的沟通，就会把瓶子里的小不满倒掉了。学习不再累积不满，是避免生气造成伤害的最好方法。
工作场所和家庭是大多人最容易產生怒气的地方，而这两个地方的对象都是非常熟悉和亲近的人，最好大家事先沟通好，有小事就直说，建立健康的沟通环境。夫妻之间，更要建立好床头吵、床尾合的默契，才能让大家都减少许多怒气的伤害。
当无法避免的怒气出现后，无论是发作或隐忍或忽略，肝火都会上升，这时最好能及时的按摩太冲穴，或回家在睡前泡泡热水脚，疏泄肝气。经常发怒的人，则最好天天做这些保养的工作，避免肝火的上升，不但能降低怒气的伤害，更能减少怒气出现的频率。