小组编码规范培训

前两天小组对某项目进行了代码走查，走查之后发现大家的编码习惯还是存在一些问题，因此上周四晚上小组针对编码规范进行了一次简单培训，本文对本次培训简要记录一下，因为编码规范远不止下文中的这几条。

1 代码表达的意思应该是简洁明了的。
我们的代码不是写给自己看的，也不是写给计算机看的，而是写给别人看的。代码表达的意思应该是简洁明了的,代码应该是自解释的。
培训实例1：
uiOffSet -= uiLen1 + uiLen2 + uiLen3; // 原始写法
代码本身是没有任何问题的，因为赋值运算符和算术运算符的优先级不同，
因此上面的代码等价于：
uiOffSet -= (uiLen1 + uiLen2 + uiLen3); // 改进写法
但是按照原始写法会给那些不知道优先级的童鞋造成误解。

培训实例2：
一个繁杂的switch语句
switch(cmd)
{
    case cmd1:fun1(...)
          break;
   
    case cmd2:fun2(...)
          break;

    case cmd3:fun3(...)
          break;

    ...

    case cmdn:funn(...)
          break;

    defalut:funk(...)
         break;
}

注：上面函数的参数都有一样的参数。
上面的代码在语法和语义上面都是OK的，但是给人的感觉总是不爽，尤其是cmd太多的情形，我们是否可以采用更好的结构对代码进行组织呢？其实很简单，创建一个函数指针(void (*pFunc[TYPE_CMD])(...))，然后建立一个映射表(cmd<--->func)，那么上面的代码就可以大幅度的进行简化了。

2 函数和变量的命名一定要准确。
命名问题是编程艺术中的重要环节,命名的水平基本和个人的能力是成正相关的，这个无需进行举例，但确实是很重要的！！！

3 编码时需要关注代码的可移植性。
由于我们的程序可能会在suse和hp两个系统下去执行，因此编写跨平台的代码
(1) 字节对齐问题；
(2) 大小端序问题；
(3) 我们的函数或变量是否是专属于某个平台的;
(4) 32位和64位系统上的指针差异。

4 一个函数表达的功能应当是单一的。
这点是unix的一个重要原则，也成为我们编码的一个准则，一个函数只完成一件事情。

 

5 代码的排版问题。
代码的排版直接影响代码阅读者的阅读心情，代码的排版能力一定程度上也是对个人逻辑思维能力的映射。

总结：每个人都有属于自己的编码风格，当一个人融入一个团队之后，应当有一个统一的风格，风格的形成体现一种素养，素养决定战斗力。