Windows客户端C/C++编程规范“建议”——函数

1 函数

1.1 代码行数控制在80行及以内

等级:【要求】

说明:每个函数的代码行数控制应该控制在80行以内。如果超过这个限制函数内部逻辑一般可以拆分。如果试图超过这个标准,请列出理由。但理由不包含如下:

  • 无法拆分。
  • 流程内部逻辑复杂,无需拆分,即使拆分了,拆分的函数也不会被其他地方用到。(解释:拆分可以减少代码行数,提炼后的函数可以方便读者快速理解函数逻辑并定位问题。)

1.2 代码列数控制在100字符及以内

等级:【要求】

说明:每行代码不可以超过100字符。如果超过这个字符数,代码的美观度和可阅读性将降低。

例子: 

for ( std::vector<ATL::CString, COneClass>::iterator it = m_VecObjects.begin(); it != m_VecObjects.end(); it++ ) 

这一行一共113列。

我们可以这么修改:

typedef std::vector<ATL::CString, COneClass>::iterator VecCStClsIter;
for ( VecCStClsIter it = m_VecObjects.begin(); it != m_VecObjects.end(); it++ )

或者使用boost/C++11中的auto:

for ( auto it = m_VecObjects.begin(); it != m_VecObjects.end(); it++ )

1.3 避免重复代码

等级:【要求】

说明:如果逻辑中重复代码行数超过30行,应该考虑将该逻辑提炼成一个函数。这样既可以增强代码可读性,还可以降低未来代码维护的代价。

1.4 函数名称不可以全大写

等级:【必须】

说明:在“1.6宏”规则中,我们已经规定宏要使用全大写方式定义。所以为了区分宏和函数,函数名不可以使用全大写。

1.5 当函数不需要返回值时不要为其设计返回值

等级:【要求】

说明:如果给不需要返回值的函数设计返回值,将为使用该函数的人带来困惑。

1.6 对于有返回值的函数要求每个退出分支都要有显示的返回值

等级:【必须】

说明:对于有返回值的函数,如果逻辑进入一个没有返回值的分支,将导致未知错误。

1.7 大内存数据参数需要使用引用传递

等级:【要求】

说明:如果不使用引用传递,则在函数调用时产生内存拷贝行为。大幅降低函数执行效率。

1.8 不会被改变的引用传递入参使用const声明

等级:【要求】

说明:避免函数中对入参修改导致逻辑出错。

1.9 入参先于出参排列

等级:【要求】

说明:这样安排一般复合理解的需要。实际上很多Windows API也是基于这样的规则设计的。

1.10 默认参数在函数定义时(非声明)使用注释标记默认值

等级:【推荐】

说明:这样将在声明定义分离的模式下,阅读者可以快速知道该函数存在默认参数的情况。

void print( int nValue = 1 );
.......
void print( int nValue /*= 1*/ ) {
	printf("%d", nValue);
} 

1.11 谨慎使用需要64位变量函数

等级:【要求】

说明:系统中很多需要64位变量的API存在于vista以上的系统中。如果我们代码中使用该类函数,将导致在XP系统上运行出错(当然可以动态加载系统dll并寻址以解决该问题)。

1.12 禁止使用非安全函数

等级:【必须】

说明:以前一批老的C函数存在不安全隐患。为了提高程序的健壮性,需使用安全版函数替代。

比较常见的非安全函数:

wcsncpy strcpy strncpy memcpy
wmemcpy sprintf wprintf vsnprintf

编译器报:

warning C4996: 'XXXX': This function or variable may be unsafe. Consider using wcsncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

解决方案:

如果是因为我们使用strsafe.h导致VC库或者可信的第三方库(比如boost)报该warning。则我们可以调整strsafe.h的包含位置等方法去除。

其他场景出现该warning,应该使用安全函数替代。这些函数的安全版本一般是在原函数后面增加_s。并新增一个空间大小的参数。

使用这些不安全函数存在以下危害:

  1. 产生脏数据。我们可能声明一个变量为1,但是经过运行后,在没有执行修改该变量的情况下,可能数据已经变成一个我们无法预计的值了。见下例n的输出。
  2. 进入错误逻辑。因为栈空间被破坏,我们的逻辑可能进入并非我们希望进入的函数内部执行。
  3. 导致崩溃。因为溢出会导致堆栈被破坏,所以极可能导致程序崩溃。由于我们栈被破坏,导致栈回溯产生错误,将严重影响我们dump的分析。
  4. 被攻击。缓冲区溢出攻击,这种攻击方式已经非常古老了。很多漏洞都是这种错误导致的。

简单的例子:

#define UNSAFE

int _tmain(int argc, _TCHAR* argv[])
{
	int m = -1;
	char buffer[8] = {0};
	int n = -1;
	std::string str = "012345678901234567890123456789";
#ifdef UNSAFE
	memcpy(buffer, str.c_str(), str.length());
#else
	memcpy_s(buffer, _countof(buffer), str.c_str(), str.length());
#endif
	printf("%d %d\n", m, n);
	return 0;
}

在release无优化的情况下,该段会产生脏数据并崩溃。(n的值已经被改变)

1.13 不要寄希望于inline声明

等级:【必须】

说明:VS平台上一个被声明为inline的函数并不一定会被内嵌到代码中,而是和普通函数一样。因为VS会依据自己的规则判断是否需要做真实的“内联”。

(转载请指明出于breaksoftware的csdn博客)

Windows客户端C/C++编程规范“建议”——函数,布布扣,bubuko.com

时间: 2024-12-25 05:16:14

Windows客户端C/C++编程规范“建议”——函数的相关文章

Windows客户端C/C++编程规范“建议”——前言

前言 工作中接触了很多编程规范.其中最有意思的是,公司最近发布了一版C/C++编程规范,然后我看到该规范的最后一段时,有这么一句:"该规范不适用于Windows平台开发".看来这份规范是由做其他平台开发的同学制定的.那么做Windows开发的人都去哪儿了?后来由于工作需要,项目组需要我制定一份编程规范.这也是我这系列博客的由来.(转载请指明出于breaksoftware的csdn博客) 说到"规范"",可能没多少人喜欢这样的东西.相信很多工程师和我一样,都

Windows客户端C/C++编程规范“建议”——函数调用

3 函数调用 3.1 谨慎使用递归方法 等级:[推荐] 说明:递归方式控制不当,可能会导致栈空间不够而崩溃.一般的递归都可以使用循环代替. 3.2 不要使用using namespace 等级:[必须] 说明:这是曾经教科书上的一种写法,但是该方法存在严重的缺陷.因为如果多个不同的namespace里定义了相同名字的变量或者函数.将导致无法预知和理解编译器最终使用的是哪个命名空间中的数据. 例子: //file1 namespace Space1{ int g_Private = 0; }; /

Windows客户端C/C++编程规范“建议”——结构

5 结构 5.1 不要使用goto 等级:[必须] 说明:在大型项目中,goto的滥用会导致灾难性后果.因为我们程序中一般不存在从一个函数体内部跳转到另一个函数体内部的场景,所以我们可以将跳转控制在函数内部,从而避免灾难. 例子: do { if ( False ) { break;// 相当于goto } } while (0); 5.2 不要利用异常机制实现流程的跳转 等级:[必须] 说明:该方法比较常见于防逆向等方面,但是我们普通编程方式应该严禁使用.否则将增加代码阅读的难度. (转载请指

Windows客户端C/C++编程规范“建议”——宏

6 宏 6.1 减少宏的使用 等级:[建议] 说明:宏的使用,将使得调试变得麻烦.所以在设计和使用宏的时候,请确保宏的逻辑是阅读者不会去关心细节的行为. 6.2 宏定义中字母需大写 等级:[必须] 说明:为了醒目表示它是一个宏,而不是一个函数. 6.3 使用const变量代替宏定义值 等级:[建议] 说明:在一个函数体内部使用的常量,最好使用const变量替代,而不是使用宏. 6.4 使用枚举代替一系列有关联的宏 等级:[建议] 说明:比如一个函数返回一系列表示状态的宏,则应该使用枚举类型替代.

Windows客户端C/C++编程规范“建议”——指针

2 指针 2.1 尽量使用智能指针 等级:[推荐] 说明:正确使用智能指针可以省去指针管理的工作. 2.2 类成员变量指针释放后一定要置空 等级:[必须] 说明:如果类成员变量指针在释放后没有置空,将出现如下问题: a) 无法判断指针是否已经是野指针 b) Dump分析很难发现是野指针函数调用导致崩溃 2.3 正确使用delete和delete[] 等级:[必须] 说明:delete[]用于释放动态分配的数组,而delete用于释放对象.两者不可以混用. 2.4 使用指针前要判空 等级:[必须]

Windows客户端C/C++编程规范“建议”——表达式和运算

4 表达式和运算 4.1 比较操作中将常量设置为左值 等级:[推荐] 说明:编写代码时,如果将常量设置为右值.可能因马虎将"=="写成"="导致逻辑错误.这种场景下,编译器是不会报错的,代码检查也比较容易被忽视. 例子: std::string::size_type index = str.find("a"); if ( index = std::string::npos){ } 上例中写法可以执行,但是逻辑是错的.如下编写,可以借助编译器检查出

Windows客户端C/C++编程规范“建议”——文件

7 文件 7.1 正确使用#include 等级:[推荐] 说明:#include <>和#include ""导致编译器在搜索文件时,搜索的路径顺序不同.所以需要正确使用#include,以避免包含错了头文件. 语法形式 操作 带引号的形式 预处理器按以下顺序搜索包含文件: 在包含 #include 语句的文件所在的同一目录中. 在当前打开的包含文件的目录中,采用与打开它们的顺序相反的顺序. 搜索从父包含文件的目录中开始进行,然后继续向上到任何祖父包含文件的目录. 跟随每

Windows客户端C/C++编程规范“建议”——风格

9 风格 9.1 优先使用匈牙利命名法 等级:[推荐] 说明:该方法由微软总设计师设计.Windows上编程最好遵从该标准.详细介绍见:http://zh.wikipedia.org/wiki/%E5%8C%88%E7%89%99%E5%88%A9%E5%91%BD%E5%90%8D%E6%B3%95 9.2 变量名结合使用匈牙利命名法和驼峰命名法 等级:[推荐] 说明:比如 int nMaxCount = 1;中变量前缀n表示int型变量,MaxCount是表意,其就是使用驼峰命名法(首字母大

Windows客户端C/C++编程规范“建议”——变量和常量

8 变量和常量 8.1 尽量不要使用全局变量 等级:[要求] 说明:全局变量的滥用和goto的滥用一样,都是一种灾难.它将使得逻辑变得难以调试和控制. 8.2 不涉及外部使用的全局变量需要使用static关键字修饰 等级:[要求] 说明:这样可以避免冲突. 8.3 变量需初始化后才能使用 等级:[必须] 说明:变量最好在定义时初始化.如果定义时无法初始化,那就应该在定义后立即初始化. 以下我们来分析下变量未初始化而被使用的场景: 在debug环境下,我们声明一个变量,编译器会使用0xCC填充变量