By John Huang

1. Objective
   
   1. To make the code easy to understand, by the original developer, and by other developers who utilize the code.
   2. To make the code easy to maintain, by the original developer, and by other developers, and to keep a consistent style over the life cycle.
   3. To make the code easy to type.
2. Class name
   
   1. Regular class should start with C. For example, CVideoFile.
   2. Utility classes, which contains only static members, should start with U. For example, UStringUtils.
   3. Stack classes, which use its constructor and destructor to store and restore some states, should start with St. For example, StWaitCursor.
   4. Each class should reside in one .cpp file and one .h file. Each file should contain only one class. The file name should be classname.cpp and classname.h. Do not omit the prefix C, U, or St.
   5. The .h file should be scoped with

#ifndef _H_classname_
#define _H_classname_

…

#endif

3. Function name
   
   1. Function names should be complete words instead of abbreviations.
   2. Each word in the function name should start with capital letter.
   3. Function names should be descriptive.
4. Parameters
   
   1. Each parameter should use prefix to indicate whether it is input value, or output value, or both

                      i.      Use “in” to indicate it is an input value. 
                      ii.      Use “out” to indicate it is an output value. 
                      iii.      Use “io” to indicate it is both input and output.

2. There is no need to use prefix to indicate the data type.
3. After the prefix, the parameter name should be complete words instead of abbreviations.
4. Each word should start with capital letter.
5. Each parameter should contain one meaning only.
4. Return value
   
   1. The return value should contain one meaning only.
   2. If multiple return values are needed, use pointer or reference parameters with “out” as prefix.
   3. Use enum type for return values that are flags.
   4. If the meaning of a return value is not obvious, it must be documented in the .h file.
5. Function body
   
   1. Block start and block end ( “{“ and “}”) should be on their own line.
   2. The block end should match its block start vertically.
   3. Normally, a function should contain less than seven lines of code.
   4. A function should never exceed the viewable area of VC. (The complete function must be viewable in VC without scrolling)
   5. Local variables should be declared just before they are used (as late as possible).
   6. Local variables should be complete words instead of abbreviations.
   7. The first word of local variable name should start with lower case. Other words in the name should start with upper case. For example, “newColor”.
6. Project
   
   1. Library projects should have a name starting with “Engine”.
   2. Projects containing internal data logic should start with “Data”.
   3. Projects containing user interface code should start with “View”.
   4. Projects that build the final exe should start with “App”.
   5. Resource projects should contains the language resource should start with “Language”.
   6. Projects that build filters should start with “Filter”.
   7. App projects should contain as little code as possible.
7. Text Format
   
   1. Use standard VC default settings for code editor format.
   2. Do not use third party code editors to avoid different look on different PCs.
   3. The width of the code should fit within the VC code editor window without horizonal scrolling.
   4. The vertical length of the each function should fit within the VC code editor window without vertical scrolling.
8. Code
   
   1. NEVER use “goto”.
   2. Do not “return”, “break” or “continue” in the middle of a loop. They make the code harder to understand, and easier to have mistakes.
   3. Do not “return” in “if…else…” unless there is no other code after the “if…else…” blocks.
9. Assembly
   
   1. Assembly code should use MS assembler.
   2. Assembly code should be accompanied by corresponding c code.

博弈论或称为赛局理论，数学的一个分支, 目前在生物学，经济学，计算机科学和其他很多学科都有广泛的应用。是研究具有斗争或竞争性质现象的数学理论和方法。也是运筹学的一个重要学科。

博弈论的创始人是冯·诺伊曼。

具有竞争或对抗性质的行为成为对策行为。在这类行为中，参加斗争或竞争的各方各自具有不同的目标或利益。为了达到各自的目标和利益，各方必须考虑对手的各种可能的行动方案，并力图选取对自己最为有利或最为合理的方案。比如日常生活中的下棋，打牌等。对策论就是研究对策行为中斗争各方是否存在着最合理的行为方案，以及如何找到这个合理的行为方案的数学理论和方法。

纳什均衡，又称为非合作博弈均衡，是博弈论的一个重要术语，以约翰·纳什命名。在一个博弈过程中，无论对方的策略选择如何，当事人一方都会选择某个确定的策略，则该策略被称作支配性策略。如果两个博弈的当事人的策略组合分别构成各自的支配性策略，那么这个组合就被定义为纳什均衡。

一个著名的例子就是囚徒困境，囚徒困境是一个非零和博弈。大意是：一个案子的两个嫌疑犯被分开审讯，警官分别告诉两个囚犯，如果两人均不招供，将被判刑1年；如果你招供，而对方不招供，则你将被判刑3个月，而对方将被判刑10年；如果两人均招供，将均被判刑5年。 于是，两人同时陷入招供还是不招供的两难处境。两个囚犯合理的选择是招供，原本对双方都有利的策略不招供和结局被判刑１年就不会出现。这样两人都选择坦白的策略以及因此被判５年的结局被称为“纳什均衡”，也叫非合作均衡。

昨天听沈总讲了一课，精彩啊！

可惜我记性不好，今天忘得差不多了。还记得的赶快写下来——

公司管理的四大要素：
（1）公司要有牵引力，让员工看到美好的前景，朝着一个方向努力；
（2）公司要有行之有效的激励机制；
（3）公司要有一定的约束机制；
（4）公司要引入良性的竞争、淘汰机制。

在150多年前，有一个牧童，在死海边上的一个洞穴内发现了一个手卷。经过专家鉴定这个手卷是犹太人的手卷，比先前发现的犹太人手卷早1000年，这就是著名的死海手卷。但是当政府去当地准备进行进一步研究的时候，手卷不翼而飞了。政府在无奈之下，只好发出告示：凡是上交手卷的，都将获得奖金。告示一出还真的有效果，陆续有人来上交手卷。凡是上交的人，哪怕是一个手卷上的小纸片，也都会得到奖励。当所有的手卷收集齐全了以后，研究者发现手卷已经无法拼回，这么一个珍贵的文物就这样被毁了。其实手卷就在当地人的手里，但是他们为了获得更多的奖励而把手卷撕毁。

由此明确一个观点：利益会让人不择手段。可能很多人不认同人性本恶的论调，包括我在内。但是应当说明的是在管理工作中根本就没有绝对的事情，因此我们必须要作必要的预防。这就如同管理工作中有一个现在比较流行的名词——授权，但授权并不是放权，管理者仍然要对权力有必要的控制。同样，我们可以以人性本善的角度进行管理工作，但是我们仍然要对各种可能发生的状况作出预防。

有这样一个故事：一把坚实的大锁挂在大门上，一根铁杆费了九牛二虎之力，还是无法将它撬开。钥匙来了，他瘦小的身子钻进锁孔，只轻轻一转，大锁就"啪"地一声打开了。 铁杆奇怪地问："为什麽我费了那麽大力气也打不开，而你却轻而易举地就把它打开了呢？" 钥匙说："因为我最了解他的心。"。

明确一个观点：任何矛盾的产生都是源于利益的冲突。中国历史上任何一次革命运动都是以人民被压迫，个人的利益无法保障的背景下发生的。利益是驱动人们采取某些行为方式的一种力量，因此利益的分配、再分配等就将引起团队中的关系变得复杂。曾经有这样一个案例：一个销售部门经理为了使得部门内有一种竞争环境，就决定在部门内实行竞争管理模式，每个月对销售量最高的那个销售人员进行额外的奖励。过去在部门内，由于没有这种竞争模式，因此大家是一个整体，也乐于互相帮助。

但是采取了奖励措施后，当有人向团队内的其他人进行求助的时候，很多人会以种种理由躲避。这种关系复杂到什么程度？大家都知道如果客户给销售人员打电话，就基本意味着合同基本可以签订下来了。但是由于奖励变成竞争，大家都不会转告当事的销售人员，某个客户打电话找他。由此而引发的公司客户流失，企业形象受损等情况十分的严重。更有甚者，有的销售人员去偷取其他人员的客户资料，甚至在客户面前诋毁自己公司的销售人员。这些都是由于奖励造成了一种竞争，而竞争最后又演变成了一种矛盾。

记得曾经听过这样一个例子：说在一个公司里，由于业绩比较好，所以总经理决定给营销部发奖金。这件事情被生产部门的员工得知了，他们想：好，一切都是营销部门的功劳，我们加班加点的生产就是理所应当的，那么我们还那么卖力作什么了。于是在第二个月的时候，公司的产品的次品率、报废率、返工率都大幅上升，成本增高，效益肯定也就大幅下降了。这就是典型的奖励变成了对别人的惩罚，难道这就是企业进行奖励的目的？

明确一个观点：行为本身是具有目的性的，人们总是会采取行动以达成一些他们认为重要的事情。很多企业在制定企业奖励计划的时候，往往主观的判断员工的工作基准。另外在很多企业的奖励计划中，对于员工个人价值观的区分并不是很详细，因此奖励计划往往也就形成了以点带面——一个标准适应所有的员工的情况。这两方面便形成了这样一种情况：企业对员工的奖励并不能引起员工的兴趣。这是典型的等价价值观的一种思维方式。关于价值观的问题由于不是本文的重点，因此也就不太多讲，只明确一个观点：每个人的价值观并不是相同的。举个例子来讲，给卖火柴的小女孩一幅精美的油画显然是没有任何意义的。我已经提过奖励的目的在于引起员工某种特定的行为，因此这个奖励对员工就要有足够的吸引力，也只有这样才能使奖励成为一种动力。

曾经听过这样一个故事。故事中有位老人和一帮孩子，爱捣蛋的孩子们总是恶作剧的漫骂老人。老人很生气但没有办法。有一天老人拿出一块钱对孩子们讲："你们说的太好了，来给你们一块钱，你们明天还要来呀。"。第二天孩子们又全都来了，在漫骂了一个小时后，老人拿出5毛钱说："给，这是你们今天的报酬。"。孩子们一看钱少了，但想一想总比没有强，便把钱接了过去。老人对他们说："明天还要来呀。"。第三天，由于有了前一天的经验，只来了一少半的孩子。当孩子又骂了两个小时以后，还没有见老人把钱拿出来，孩子们便要散去了。老人对远走的孩子讲，明天还要来呀。孩子们大声的说："不给钱谁还来呀。"。从那以后再也没有孩子来骂老人了。

为什么老人明明是"奖励"孩子们来骂他，但最后孩子们却都没有来骂呢？这就是奖励变成了另外一种形式的惩罚。看看企业的奖励计划吧，奖励的金额变得越来越低，奖励的标准变得越来越高，奖励就已经成为了一种惩罚。这个时候企业内部最容易形成对组织毫无意义的非正式组织，员工会用自己的形式来进行对抗和保护，例如降低产量和减小业务成交量。奖励的作用是激励，而不应当成为一种惩罚，因此在进行奖励计划设计时一定要注意这种转变。