没有合适的资源?快使用搜索试试~ 我知道了~
首页C++编程规范:文件结构与版权声明
本文档主要探讨了C++/C编程的规范与质量控制,强调了编写高质量代码的重要性。文档内容分为两个章节,首先是关于文件结构的管理。 第1章着重于程序的组织方式,指出一个典型的C++/C项目包含一个头文件(.h)和一个定义文件(.c或.cpp,或在某些系统中为.cc或.cxx)。在文件开始时,必须包含版权和版本信息,如文件名称、作者、版本号、完成日期以及版本历史,以确保知识产权的明确和项目管理的清晰性。例如,版权和版本声明应遵循特定格式,如示例1-1所示。 头文件的结构包括版权和版本声明、预处理指令块、函数和类的声明等。为了防止头文件被无意中多次包含,使用ifndef/define/endif结构进行条件编译,标准库头文件使用#include<filename.h>,非标准库则用#include"filename.h"。文档建议在头文件中仅存放函数和类的声明,避免定义,以保持代码的一致性和可维护性。尽管C++允许在声明时定义内联函数,但为保持良好的编程风格,建议将函数定义与声明分开。 此外,文档强烈反对在头文件中过度使用全局变量,因为这可能导致代码耦合度增加,不易理解和测试。尽量将全局变量限制在最小范围内,或者使用局部变量和类成员变量来代替。 总结来说,这篇文档提供了一套C++/C编程的编码规范,旨在提升代码质量,通过明确的文件结构、版权声明、预处理指令的使用以及对内联函数和全局变量使用的指导,帮助开发者编写出更加模块化、可读性强的代码。遵守这些规范将有助于提高项目的整体效率和可维护性。
资源详情
资源推荐
规则2-7-1注释是对代码的“提示”,而不是文档。程序中的注释不可喧宾夺主,注释
太多了会让人眼花缭乱。注释的花样要少。
规则2-7-2如果代码本来就是清楚的,则不必加注释。否则多此一举,令人厌烦。例
如
550 加 ,多余的注释
规则2-7-3边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一
致性。不再有用的注释要删除。
规则2-7-4注释应当准确、易懂,防止注释有二义性。错误的注释不但无益反而有害
规则2-7-5尽量避免在注释中使用缩写,特别是不常用缩写。
规则2-7-6注释的位置应与被描述的代码相邻,可以放在代码的上方或右方,不可放
在下方。
规则2-7-8当代码比较长,特别是有多重嵌套时,应当在一些段落的结束处加注释,
便于阅读。
示例E程序的注释
2.8 类的版式
类可以将数据和函数封装在一起,其中函数表示了类的行为(或称服务)。类提供关
键字public、protected和private,分别用于声明哪些数据和函数是公有的、受保护的或者
是私有的。这样可以达到信息隐藏的目的,即让类仅仅公开必须要让外界知道的内容,而
隐藏其它一切内容。我们不可以滥用类的封装功能,不要把它当成火锅,什么东西都往里
扔。
类的版式主要有两种方式:
(1)将private类型的数据写在前面,而将public类型的函数写在后面,如示例8-3(a)。
采用这种版式的程序员主张类的设计“以数据为中心”,重点关注类的内部结构。
(2)将public类型的函数写在前面,而将private类型的数据写在后面,如示例8.3(b)采
用这种版式的程序员主张类的设计“以行为为中心”,重点关注的是类应该提供什么样的接
口(或服务)。
/*
* 函数介绍:
* 输入参数:
* 输出参数:
* 返回值 :
*/
void Function(float x, float y, float z)
{
…
}
if (…)
{
…
while (…)
{
…
} // end of while
…
} // end of if
很多C++教课书受到Biarne Stroustrup第一本著作的影响,不知不觉地采用了“以数据
为中心”的书写方式,并不见得有多少道理。
我建议读者采用“以行为为中心”的书写方式,即首先考虑类应该提供什么样的函数。
这是很多人的经验——“这样做不仅让自己在设计类时思路清晰,而且方便别人阅读。因
为用户最关心的是接口,谁愿意先看到一堆私有数据成员!”
3
6
G0
H20
.
:6
/ 0
/ 0
.
4
3
:6
/ 0
/ 0
.
6
G0
H20
.
4
示例8.3(a) 以数据为中心版式 示例8.3(b) 以行为为中心的版式
第3章 命名规则
比较著名的命名规则当推Microsoft公司的“匈牙利”法,该命名规则的主要思想是“在
变量和函数名中加入前缀以增进人们对程序的理解”。例如所有的字符变量均以为前缀
若是指针变量则追加前缀。如果一个变量由开头,则表明它是指向字符指针的指
针。
“匈牙利”法最大的缺点是烦琐,例如
GI0
H2<0
倘若采用“匈牙利”命名规则,则应当写成
(JI0前缀 表示类型
H##K#L0前缀 #表示H类型
如此烦琐的程序会让绝大多数程序员无法忍受。
据考察,没有一种命名规则可以让所有的程序员赞同,程序设计教科书一般都不指定
命名规则。命名规则对软件产品而言并不是“成败悠关”的事,我们不要化太多精力试图发
明世界上最好的命名规则,而应当制定一种令大多数项目成员满意的命名规则,并在项目
中贯彻实施。
3.1 共性规则
本节论述的共性规则是被大多数程序员采纳的,我们应当在遵循这些共性规则的前提
下,再扩充特定的规则,如3.2节。
规则3-1-1标识符应当直观且可以拼读,可望文知意,不必进行“解码”。
标识符最好采用英文单词或其组合,便于记忆和阅读。切忌使用汉语拼音来命名。程
序 中 的 英 文 单 词 一 般 不 会 太 复 杂 , 用 词 应 当 准 确 。 例 如 不 要 把 C u r r e n t Va l u e写 成
NowValue。
规则3-1-2标识符的长度应当符合“,>>,2#,=原则。
几十年前老ANSI C规定名字不准超过6个字符,现今的55不再有此限制。一般来
说,长名字能更好地表达含义,所以函数名、变量名、类名长达十几个字符不足为怪。那
么名字是否越长约好?不见得M例如变量名,2就比,2N OPH8好用。
单字符的名字也是有用的,常见的如GI,2<等,它们通常可用作函数内的局部变
量。
"
规则3-1-3命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
例如Windows应用程序的标识符通常采用“大小写”混排的方式,如AddChild。而Unix
应用程序的标识符通常采用“小写加下划线”的方式,如add_child。别把这两类风格混在一
剩余63页未读,继续阅读
Jasper-Chou
- 粉丝: 4
- 资源: 4
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 计算机人脸表情动画技术发展综述
- 关系数据库的关键字搜索技术综述:模型、架构与未来趋势
- 迭代自适应逆滤波在语音情感识别中的应用
- 概念知识树在旅游领域智能分析中的应用
- 构建is-a层次与OWL本体集成:理论与算法
- 基于语义元的相似度计算方法研究:改进与有效性验证
- 网格梯度多密度聚类算法:去噪与高效聚类
- 网格服务工作流动态调度算法PGSWA研究
- 突发事件连锁反应网络模型与应急预警分析
- BA网络上的病毒营销与网站推广仿真研究
- 离散HSMM故障预测模型:有效提升系统状态预测
- 煤矿安全评价:信息融合与可拓理论的应用
- 多维度Petri网工作流模型MD_WFN:统一建模与应用研究
- 面向过程追踪的知识安全描述方法
- 基于收益的软件过程资源调度优化策略
- 多核环境下基于数据流Java的Web服务器优化实现提升性能
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功