c++开发规范

1  C++开发编码规范
1.1  文件夹命名:
采用全小写,多个单词之间直接连接。由于文件夹数量相对比较少,我们使用一两个单词就可以表达清楚,所以这种命名方式足够了。

名称一般要体现名词性。

例如:

framework、webwatch、yahoohttp、chat163、msnudpfile



1.2  文件命名:
建议文件名全部用小写,因为Windows不去区分大小写,多个单词用_来隔开

1.3  类命名:
类名:采用每个单词首字母大写,单词其余部分全小写,多个单词之间直接连接;只有一个单词,首字母也要大写。(与文件名命名相同)

名称一般要体现名词性。

例如:

class Chat {…};class LineReader {…};

class CommandParser {…};class DBQueryPool {…};



成员函数名:采用首单词全小写,其余单词首字母大写,多个单词之间直接连接;只有一个单词,全小写。

名称一般要体现动词性,单个动词或动宾结构。

例如:

class LineReader

{

public:

   int push(void * buf, int size);

   int getLine(void * buf, int size);

   int getLineLen();



private:

   void moveData(int copyLen);



private:

   int _count;

   int _bufIndex;

   int _bufSize;

    char * _pBuf;

};

成员变量名:以下划杠开头,  之后部分和成员函数名命名方式一样。例子参见上面代码片段。

名称一般要体现名词性。



1.4  结构体命名:
与1.3类名命名相同。

名称一般要体现名词性。

例如:

typedef struct DataTrunk

{

   unsigned int       _type;

   char               _data[256];

   void *             _pData;

   struct DataTrunk * _pNext;

} DataTrunk;



1.5  枚举命名:
枚举名:与1.3类名命名相同。

成员名:所有字母大写,各单词之间用下划杠分隔。

名称一般要体现名词性。

例如:

enum DataTrunkType

{

   ETHER_PKG = 0,

   IP_PKG = 1,

   UDP_PKG = 2,

   TCP_PKG = 3,

   MSG_STARTUP = 4,

   MSG_SHUTDOWN = 5,

   MSG_LOAD = 6,

   MSG_UNLOAD = 7,

  TCP_STREAM = 8

};



1.6  宏命名:
所有字母大写,各单词之间用下划杠分隔。

名称一般要体现名词性。

例如:

#define IPCHAIN_SIZE  64

#define PACKDIR_OUT   0

#define PACKDIR_IN    1

#define PACKDIR_OTHER 2



1.7  全局函数:
所有字母小写,各单词之间用下划杠分隔。

名称一般要体现动宾结构。

例如:

int init_db_pool();



void parse_mail(char * data, string & from);



1.8  静态函数:
所有字母小写,各单词之间用下划杠分隔。

名称一般要体现动宾结构。

记住需要添加static关键字。

例如:

static void process_db_pool();



1.9  指针、全局变量、局部静态变量:
全局变量:以小写g开头。例如:

int gPoolSize = 0;

char gHostName[128] = {0};



局部静态变量:以小写s开头。例如:

static int sLoopCount = 0;

static char sBlackList[256] = {0};



指针类型变量:以小写p开头。例如;

char * pBuf = NULL;

int * pBufLen = NULL;

char * _pBuf;             // 类成员变量

char * gpHostName = NULL; // 全局的指针类型

static int * spLoopCount = 0; // 静态的指针类型



1.10  函数设计:
l        代码行长度:

鉴于我们现有的显示器屏幕高度在45~65行之间,而宽度在100列左右。

一个函数体,代码行数原则上控制在40行以内,最多不要超过80行,也就是在vim编辑器里,大多数函数不用翻屏就能看完,少数函数最多也就上下翻动一屏,以提高可读性。

而一行代码,最长不能超过90列,超过了就应该手工分行。

注意:函数体应该是一个高内聚的功能体,我们首先应该从它所表达的功能单元来考虑提取一个函数,函数名应该明确表达其实现的功能;而死死数代码行数,以为在80行以内就是好函数,这是错误的。

建议:类成员函数应该短一些,控制在40行以内;而全局函数和局部静态函数,相对于类成员函数,代码行可以长一点。



l        函数参数命名:

采用首单词全小写,其余单词首字母大写,多个单词之间直接连接;只有一个单词,全小写。

int readLine(void * pBuf, bool allwaysReturn);

l        函数体内变量命名:

如果函数体控制在适当大小,功能高内聚,那么我们不需要定义太多局部变量,所以临时变量可以采用简单的单词来命名,全部小写,如果实在比较长,则采用首单词全小写,其余单词首字母大写,多个单词之间直接连接。

例如:

int i = 0;

int len = 0;

bool flag = true;

int tcpport = 80;

char * pName = NULL;



l        花括号对齐:

int parse_mail( )

{

   if( … )

   {

   }



   return 0;

}



l        代码行缩进:

代码行要按通常模式缩进,必须使用tab来缩进;千万不要使用敲空格来缩进。因为在用编辑器来阅读时,有人习惯2列缩进,而有人习惯4列缩进,他们可以自己设置自己喜欢的缩进方式,动态处理tab的显示效果,如果用敲空格来缩进,就固定死了。例如在.vimrc里设置:

set shiftwidth=4

set tabstop=4

而有些人可能设置:

set shiftwidth=2

set tabstop=2



1.11  类设计:
不要设计一个功能大而全的类。

类公共接口数控制在8个以内。(贝尔实验室研究错误率后建议的数量,<<重构>>作者Martin Fowler建议的数量)

在明确需要提供拷贝构造函数和赋值构造函数时,一定要实现,比如成员变量有指针,并在构造函数里分配而在析构函数里释放了动态内存时;如果不想提供,则可以明确private化,以免误用值传递。



1.12  源代码文件设计:
l        头文件:

一定要有预编译宏:

#ifndef _SESSION_MANAGER_H_

#define _SESSION_MANAGER_H_



//这里声明你的全局函数、类等



#endif//_SESSION_MANAGER_H_

类、结构体、枚举要有功能说明。

全局函数、public型成员函数要有功能说明,最好添加参数说明和返回值说明,而private型则可有可无。

函数头的说明,建议采用doxygen格式编写,以后可以使用doxygen来自动生成说明文档。



/*

* 打开文件

* @param [in] pFileName 文件名

* @param [in] mode 打开模式: 0-读,1-写,2-读写

* @return 0—成功,-1—失败

*/

int open_file(const char * pFileName, int mode);



l        源文件:

不要乱引用头文件,只保留应该引用的头文件,以减少依赖,加快编译速度。

文件行数最多不要超过500行。因为平均一个函数控制在50行的话,一个文件里写10左右的函数就够多了,用vim上下翻动10屏以上是很辛苦的。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
 C++领域20年集大成之作   两位世界专家联袂巨献   适合所有层次C++程序员   良好的编程规范可以改善代码质量,缩短上市时间,提升团队效率,简化维护工作。在本书中,两位全世界受尊敬的C++专家将全球C++社区的集体智慧和经验凝结成一整套编程规范。这些规范可以作为每一个开发团队制定实际开发规范的基础,更是每一位C++程序员应该遵循的行事准则。   本书涵盖了C++程序设计的每一个方面,包括设计和编码风格、函数、操作符、类的设计、继承、构造与析构、赋值、名字空间、模块、模板、泛型、异常、STL容器和算法等。书中对每一条规范都给出了言简意赅的概述,并辅以实例说明;另外还给出了从类型定义到错误处理等方面的大量C++实践,包括许多总结和标准化的技术。即使使用C++多年的程序员也会从中受益匪浅。   通过阅读本书,可以找到以下问题的答案。   哪些东西值得标准化?哪些东西不值得标准化?   使代码可扩展的方法是什么?   合理的错误处理策略有哪些要素?   如何(和为什么要)避免不必要的初始化、循环依赖和定义依赖?   何时应该(以及如何)同时使用静态和动态的多态性;   如何实践“安全的”改写?   何时该提供不会失败的交换?   为什么阻止异常跨越模块边界传播?如何阻止?   为什么不应该在头文件中写名字空间声明或指令?   为什么应该使用STL vector和string代替数组?   如何选择正确的STL搜索或排序算法?   为了保证代码的类型安全,应该遵从哪些规则?

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值