分布式内存数据库﹒morpheus﹒c代码风格.docx

Entity Grid C++开发组代码风格 Owner/Author:Vincent Zhang(张斌)Improvement:ComponentEnity GridSub-component:Entity Grid DOCPROPERTY Component NameDocInformation:Component NameRelease/Milestone:StatusDraft简介 正确使用C++，可以同时获得在开发效率和执行效率上的效益。本文档规定一些编码风格和语言用法上的约束，目的是保证小组内C++代码清晰、可读并且非常高效。本文档基于 HYPERLINK /svn/trunk/cppguide.xml google coding style，不同处在于本文档对C++的使用限制更少，并且增加了C++11的特性描述，来提高开发效率和代码执行效率。通常，本文档的条目可以在 HYPERLINK /svn/trunk/cppguide.xml google coding style中获得更多参考信息。 一般问题 头文件 是否正确使用头文件，会极大地影响到代码的可读性，生成的代码规模和执行性能。一般来说，所有组件都应该尽量以代码库的思维来设计，并且尽量避免.cpp文件。这种做法有以下好处：避免动态链接，组件可以独立开发、测试和维护，组件重用性高。 例子：Entity Grid中的Storage Layer是一个可独立测试的通用组件，不依赖于Entity Grid中任何其他部分，可以用于其他项目。 头文件使用.h后缀。 #define哨位 所有头文件必须使用#define哨位来避免重复包含。哨位符号格式如下：MODULE_NAME_FILE_H_ 最小包含原则 不包含不需要的头文件。在可能的情况下，使用一个前置声明来代替头文件包含。简单地说，如果一个头文件中没有使用到一个类的成员，那么这个头文件中只需要这个类的前置声明就足够了。 inline函数 10行以上的函数不允许声明为inline。仅当一个函数在10行以下的时候考虑使用inline。Inline的意思是：编译器会在调用点直接插入函数的内容，从而避免了在运行时一次函数调用的开销。这将提高执行效率，但会增大代码尺寸。注意：1)在类声明之中的成员函数将自动声明为内联函数2) inline关键词只能和函数实现放到一起。譬如： class memory_block { void * _data; size_t _size; public: void* address() const; size_t* size() const { return _size;} }; inline void * memory_block:: address() const { return _data ? _data-data : 0;} 例1：class memory_block .impl.h文件 鼓励一个类在一个单独的头文件中实现。如果出于代码整洁的考虑需要将类的定义和实现分离，有两个选择： 紧随类声明之后，实现该类(参考例1的memory_block::address实现) 将类实现放到一个.impl.h文件中，并在类声明结束后包含该文件 函数参数的顺序 设计函数参数的时候，将输入参数放到前面，输出参数放到后面。通常，输入参数要么是值类型如int，要么是const?reference类型。避免在函数参数中使用指针。 头文件声明顺序 C系统文件，如cstring, linux/types.h C++系统文件，如fstring 其他库.h文件，如boost/property_tree/property_tree.hpp 本项目?.h文件 作用域（Scoping） Namespace 使用namespace来组织模块，在需要时使用namespace来掩藏实现 将尽可能少的名字暴露给外部，不引入不需要的名字 鼓励在实现文件中使用unnamed namespace来掩藏实现细节 一个模块不应该扩展其他模块的名字空间，譬如程序中不应该将任何类放到std名字空间下 不允许使用using namespace xxx，相反，用到什么名字就声明什么名字：using std::string; using boost::property_tree::property::tree; 鼓励使用名字空间+名字：std::string name; 允许使用别名:namespace sto=mevo::storage; 全局变量和静态变量 不允许全局变量。全局变量意味着