语法高亮
几乎所有的现代源码编辑器均不同在程度上支持语法高亮显示的功能。缤纷的色彩不但可以吸引MM们的目光,还可以在很大程度上帮助我们阅读那些奥涩如咒语般的源代码。 统一的语法高亮规则不仅能让我们望色生意,还可以帮助我们阅读没有 编码规范,或者规范执行很烂的源码。 所有在文档中出现的代码段均必须严格符合下表定义的语法高亮规范。在编辑源码时,应该根据编辑器支持的自定义选项最大限度地满足下表定义的高亮规范。
|
文件结构
文件头注释
|
所有C++的源文件均必须包含一个规范的文件头,文件头包含了该文件的名称、功能概述、作者、版权和版本历史信息等内容。标准文件头的格式为:
如果该文件有其它需要说明的地方,还可以专门为此扩展一节:
每行注释的长度都不应该超过80个半角字符。还要注意缩进和对其,以利阅读。 关于文件头的完整例子,请参见:文件头例子 关于文件头的模板,请参见:文件头注释模板 |
头文件
头文件通常由以下几部分组成:
头文件的编码规则:
关于头文件的完整例子,请参见:头文件例子 |
内联函数定义文件
如上所述,在内联函数较多的情况下,为了避免头文件过长、版面混乱,可以将所有的内联函数定义移到一个单独的文件中去,然后再用#include指令将它包含到类声明的后面。这样的文件称为一个内联函数定义文件。 按照惯例,应该将这个文件命名为“filename.inl”,其中“filename”与相应的头文件和实现文件相同。 内联函数定义文件由以下几部分组成:
内联函数定义文件的编码规则:
关于内联函数定义文件的完整例子,请参见:内联函数定义文件例子 |
实现文件
实现文件包含所有数据和代码的实现体。实现文件的格式为:
实现文件的编码规则:
关于实现文件的完整例子,请参见:实现文件例子 |
文件的组织结构
由于项目性质、规模上存在着差异,不同项目间的文件组织形式差别很大。但文件、目录组织的基本原则应当是一致的:使外部接口与内部实现尽量分离;尽可能清晰地表达软件的层次结构…… 为此提供两组典型项目的文件组织结构范例作为参考:
|
命名规则
如果想要有效的管理一个稍微复杂一点的体系,针对其中事物的一套统一、带层次结构、清晰明了的命名准则就是必不可少而且非常好用的工具。 活跃在生物学、化学、军队、*、黑社会、恐怖组织等各个领域内的大量有识先辈们都曾经无数次地以实际行动证明了以上公理的正确性。除了上帝(设它可以改变世间万物的秩序)以外,相信没人有实力对它不屑一顾 在软件开发这一高度抽象而且十分复杂的活动中,命名规则的重要性更显得尤为突出。一套定义良好并且完整的、在整个项目中统一使用的命名规范将大大提升源代码的可读性和软件的可维护性。 在引入细节之前,先说明一下命名规范的整体原则:
类/结构
|
除了异常类等个别情况(不希望用户把该类看作一个普通的、正常的类之情况)外,C++类/结构的命名应该遵循以下准则:
不同于C++类的概念,传统的C结构体只是一种将一组数据捆绑在一起的方式。传统C结构体的命名规则为:
|
函数
|
变量
变量应该是程序中使用最多的标识符了,变量的命名规范可能是一套C++命名准则中最重要的部分:
|
常量
C++中引入了对常量的支持,常量的命名规则如下:
|
枚举、联合、typedef
枚举、联合及typedef语句都是定义新类型的简单手段,它们的命名规则为:
|
宏、枚举值
|
名空间
C++名空间是“类”概念的一种退化(相当于只包含静态成员且不能实例化的类)。它的引入为标识符名称提供了更好的层次结构,使标识符看起来更加直观简捷,同时大大降低了名字冲突的可能性。 名空间的命名规则包括:
|
代码风格与版式
代码风格的重要性怎么强调都不过分。一段稍长一点的无格式代码基本上是不可读的。 先来看一下这方面的整体原则:
|