Xt命名规范整理

常用编码规范

• pascal命名风格：标识符所有单词首字母大写，其他字母小写，单词尽量采用缩写形式，如：void GetIntFromStr()
• camel命名风格：标识符第一个单词所有字母小写，其他单词首字母大写，其他字母小写，单词尽量采用缩写形式，如：void getIntFromStr()
• 匈牙利命名风格：标识符以一个或者多个小写字母开头作为前缀，该前缀指明标识符的作用域、类型等属性，之后的是首字母大写的一个单词或多个单词组合，如：int iLineCount表明其为整型变量
  下划线命名风格：标识符每个单词之间加下划线分离，单词字母均为小写，如：void get_int_from_str()

命名

• 1．Namespace
  命名空间名称全部采用小写，例如net::class::space
  代码文件中尽量用命名空间前缀访问变量，特别是头文件中
  项目相关代码应该放在项目自己的命名空间中
  Namespace不要使用RZ字样开头或结尾

• 2．Class
  Class命名采用pascal命名规范，首字母大写
  案例

    class DocumentMaintainer    {    };

成员函数采用camel风格，首字母小写，如：void setValue()
成员变量采用camel风格，但是需要加m_前缀，如：int m_myBook
静态成员函数采用camel风格
静态成员变量采用camel风格，但是需要加s_前缀，如：int s_myBaby

讯投代码中一般成员变量会用前缀标记类型，实际情况如下

private:    string                  m_strAcccountId  /*账号名称*/    string                  m_strPassword    /*密码*/    int                     m_nPlatformID    /*平台ID*/

• 3．全局标识符

  全局变量采用camel风格，但是需要加g_前缀。注意：全局变量一定要在.cpp文件中定义，且做初始化赋值，头文件中只能做外部引用说明。如：
  .cpp文件:
  double g_thisIsGloalVar = 0.0;
  .h文件:
  extern double g_thisIsGloalVar;

• 4．局部标识符
  ·局部变量采用camel风格
  ·局部静态变量采用camel风格

• 5．函数形参
  ·采用camel风格

• 6．常量
  ·使用单词大写加下划线风格，如：
  const int MAX_USER_COUNT = 1024;

• 7． 宏定义
  宏定义的宏名称使用单词大写加下划线风格，如：
  #define MAX_USER_COUNT 1024
  带参数宏定义的参数一般采用camel风格，如：
  #define MAX(x, y) (x < y ? y : x)
#define UNION(dataSet1, dataSet2) (......)

• 8 . struct、union、enum
  类型名使用pascal风格，成员使用camel风格（enum成员用常量命名方式），建议使用typedef方式定义，如：

typedef struct tagPackageHeader{    Int32 length;    Byte version;}PackageHeader;typdef enum tagEncryptMethod{    ENCRYPT_NONE = 0,    ENCRYPT_DES = 1,    ENCRYPT_AES = 2,}EncryptMethod;typedef union tagReturnValue{    char[16] errorStr;    Int32 errorNum;    Int64 errorCode;}ReturnValue;// 实际struct结构定义如下struct CAuthLimit{    CAuthLimit();    int     m_nStartTime;        // 开始时间    int     m_nEndTime;          // 截至时间    double  m_dMaxQuota;         // 最大比率（用于资金管理）};

• 9．文件命名
  ·头文件和.cpp文件能一一对应的，文件名要相同，采用pascal风格，并且文件名要能准确概括文件内容

• 10 . 避免使用下划线
  ·除了以上约定的情况外，其他标识符不要使用下划线，特别是在标识符头和尾，决不能使用下划线。

• 11 . 标识符命名不要重复

  • 不要与编程语言的关键词相同
  • 不要与系统库的标识符重复
  • 尽量避免与第三方库标识符重复，如果有相同标识符，要带命名空间名字访问
  • 不要在相同的作用域中申明重复的标识符，不要在嵌套作用域中申明重复的标识符

• 12 . 标识符命名要体现其含义
  实现自我注释，保持可阅读性

排版

• 1 . 头文件格式样例
  文件说明

    ......    include <xxxx.h>    ……    宏定义    …..    前向引用申明    ……    struct/enum/union申明    ……    class申明    ……    全局变量引用申明    ……    include <模板实现文件>

• 2 .cpp文件格式样例
  文件说明

    ......    include <xxxx.h>    ……    宏定义    …..    全局变量定义    ……    全局函数定义    ……    Class 实现

• 3 . 缩进
  ·所有的代码缩进必须用空格代替tab，缩进的宽度为4个空格，不允许使用tab键作为缩进符

• 4 . 行宽
  ·所有的单行代码最好不要超过120个字符，如果超过需要手动分行。对表达式进行换行时，尽量在低优先级操作符处换行，且操作符在新行行首，并作适当缩进

• 5 . 代码管理
  ·代码的实现最好全部写在.cpp文件中，头文件中只写申明，不写实现；模板类代码建议放在.hpp文件中，并在头文件中包含该.hpp文件
  ·代码分界符“｛”和“｝”单独占行，如：
  建议做法：

void setValue(int value){    m_value = value;}

• 6 . 空行

·头文件中不同数据结构之间需要用一个空行分离
·函数体内功能相对独立的代码块之间需要用一个空行分离
·函数之间需要用一个空行分离
·其他功能块之间，建议用一个或两个空行分离
·行注释之前需要一个空行分离

• 7 . 条件、循环语句

关键词之后需要加一个空格再写条件表达式，并且所有代码都要包含在大括号内，那怕只有一行代码，如：

if (i < maxValue){    i++;}while (i < maxValue){    i++;}switch (i){case 1:    {    break;    }case 2:    {    break;    }default：    {    break;    }}

• 8 . 操作符
  ·双目操作符与操作数之间需要用空格隔开，单目操作符与操作数之间不能加空格，“->”和“.”前后不能加空格。例子：
  正确做法：
  c = a + b
d++
++d
  错误做法：
  c=a+b
d ++
++ d
  ·当一个表达式有多个操作符时，在不明确优先级时，要用括号强制操作符的优先顺序，如：
  a & b + c / d | e & f 应该这样写：a & (b + (((c / d) | e) & f))

• 9 . 逗号、分号

  用以表达式和代码分离的逗号和分号，需要在其后添加空格。

注释

注释统一采用JavaDoc风格，从而可用doxygen生成帮助文档。注释一般放在行尾或者独立占用若干行，不鼓励在代码行的中间书写注释，独立占行的注释一定要在被注释代码之的上方，且一般情况下与前面代码之间用空行隔离。如果代码修改，相应的注释一定要做相应的修改，不能让注释和代码表述不一致。注释尽量用中文书写。

独立行注释：

double businessAmount;double charge;double earnBalance;/* 计算手续费和收益 */charge = businessPrice * businessAmount * 300 * m_ifFillFee;earnBalance = (businessPrice - holdAvgPrice) * businessAmount * 300;// 同行行尾注释：double businessAmount; /* 成交量 */double charge;         /* 手续费 */double earnBalance;    /* 收益 */charge = businessPrice * businessAmount * 300 * m_ifFillFee;  /* 计算手续费 */

• 1 . 文件注释
  ·对代码文件要写注释，项目至少包括：实现的功能、作者、日期、特殊说明，有必要时，要书写使用范例。

/*** IFOBDispatcher.h** 期货相关业务的处理** @author       abc* @version      1.0* @date         2012-03-09*/

• 2 . 数据结构注释
  ·为每一个数据结构的定义书写注释，并且具体到每一个成员

• 3 . 变量注释
  变量的简单注释放于变量申明的行尾，复杂的注释放于变量声明的上方。
  ·全局变量一定要书写注释
  ·静态变量一定要书写注释
  ·局部变量不能自我解释的要书写注释
  ·成员变量不能自我解释的要书写注释
  ·函数形参不能自我解释的要书写注释，注释放于函数注释中

• 4 . 函数注释
  函数的注释放于函数申明的上方，要指明该函数实现的功能、参数列表和返回值。
  ·全局函数一定要书写注释
  ·静态函数一定要书写注释
  ·成员函数不能自我解释的或者参数过于复杂的需要注释

/** * processLogin()* 负责登录请求的处理* @param req 请求包* @param userName 用户名* @return 操作结果，SUCCESS_SUCCESS表示成功，其他表示失败的错误号*/TLInt32 processLogin(shared_ptr<IFOBRequest> req, const string& userName);

• 5 . 代码注释
  ·有复杂逻辑的代码块一定要详细注释，并指明可能发生的问题
  ·条件语句要书写注释，并指明边界条件

-6 . 风格统一
代码中所有注释风格要统一，也就是说对每一种功能的注释排版要一致。

程序

基本规则：代码组织越简洁越好、程序效率越高越好。

• 1 . 不再需要的代码一定要去掉
  不再需要的变量、代码和注释不要留在程序中，且不要用注释的形式保留在程序中，除非有可能需要恢复。尽量保持代码的干净和整洁。

• 2 . 一行代码最好只写一条语句
  不要在一行代码写多条语句，特别是变量申明的时候，这样既便于注释，也便于阅读，如：
  不建议做法：
  double curMoney, initMoney, tmpValue;
  建议做法：
  double curMoney;
double initMoney;
doube tmpValue;

• 3 . 函数实现的功能尽量单一
  不要奢望一个函数完成多个功能，复杂的功能要分割成多个函数处理。

• 4 . 函数的参数尽量简化
  函数的参数不要过多，函数的返回值尽量不要使用参数返回。

• 5 . 函数的大数据结构参数尽量使用引用或指针
  对于大数据结构的参数，最好使用引用或者指针传递，但要保证作用域有效，防止提前析构。

• 6 . 多线程使用的函数要确保可重入
  对公共变量要进行访问保护，但要注意死锁发生。

• 7 . 不要过多使用全局变量和静态变量
  全局变量和静态变量使程序难以维护，并且会加大模块之间的耦合度。

• 8 . 合理选用数据结构
  组织数据时，要合理选用数据结构，常用数据结构有：
  链表类（如STL的deque）：用于头尾两端操作比较合适
  数组类（如STL的vector）：用于固定下标操作比较合适
  字典类（如STL的map）：用于随机访问操作比较合适
  一般情况下，对10个以上的数据组进行频繁查找、删除或者添加时，要用字典类结构，且使用迭代器访问，以增加操作效率，不要使用数组或者链表类结构（如vector，list）。

• 9 . 不要使用晦涩难懂的语句，不用使用高度复杂的编程技巧
  除非简单的方式达不到目标，避免把自己和别人绕晕。

• 10 . 变量使用前要初始化
  特别是作为右值使用时

• 11 数据一处整理，多处使用
  数据的整理相对耗时，尽量一处整理，多处使用，不要每次使用时都进行处理。

• 12 . 完整处理错误条件
  据统计，程序中有20%左右的代码是对错误（或者异常）情况进行处理。每一种错误情况都需要进行合理处理，因为错误往往是发生于边界条件下，一个程序的健壮性正是体现在边界条件的处理完善与否。

• 13 . 减少程序耦合度
  函数与函数之间、模块与模块之间、系统与系统之间的接口数量要少，调用次数要少，调用地方要少。

• 14 . 对被频繁调用的函数要注意优化
  比如参数传递的优化、循环语句的优化、数据处理的优化等。

• 15 . 代码行数少，不代表执行时间少

• 16 . 简单的条件判断不影响效率，程序中要多做判断

文档开发，这个模块完全放弃

因为基本上就没有人写文档。