【规则 6-1-1】参数的书写要完整，不要贪图省事只写参数的类型而省略参数名字。
【规则 6-1-2】参数命名要恰当，顺序要合理。 参数的顺序要遵循程序员的习惯。一般地，应将目的参数放在后面，源参数放在前面。表示从哪里到哪里（取从左到右的含义）
【规则 6-1-3】如果参数是指针，且仅作输入用，则应在类型前加 const，以防止该指针在函数体内被意外修改
【规则 6-1-4】如果输入参数以值传递的方式传递对象，则宜改用“const &”方式来传递，这样可以省去临时对象的构造和析构过程，从而提高效率。
【建议 6-1-2】尽量不要使用类型和数目不确定的参数。
C 标准库函数 printf 是采用不确定参数的典型代表，其原型为：int printf(const chat *format[, argument]…);这种风格的函数在编译时丧失了严格的类型安全检查
6.2 返回值的规则
【规则 6-2-1】不要省略返回值的类型。
C 语言中，凡不加类型说明的函数，一律自动按整型处理。这样做不会有什么好处，却容易被误解为 void 类型。
C++语言有很严格的类型安全检查，不允许上述情况发生。由于 C++程序可以调用C 函数，为了避免混乱，规定任何 C++/ C 函数都必须有类型。如果函数没有返回值，那么应声明为 void 类型
【规则 6-2-3】不要将正常值和错误标志混在一起返回。正常值用输出参数获得，而错误标志用 return 语句返回。
6.3 函数内部实现的规则
不同功能的函数其内部实现各不相同，看起来似乎无法就“内部实现”达成一致的观点。但根据经验，我们可以在函数体的“入口处”和“出口处”从严把关，从而提高函数的质量。程序员守则：对他人保持悲观，对设计追求全面
【规则 6-3-1】在函数体的“入口处”，对参数的有效性进行检查。（我们不能保证调用者有完好的代码风格，只能保证我们自己的代码有足够的健壮性去容错）
return 语句不可返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁。例如
char * Func(void) { char str[] = “hello world”; // str 的内存位于栈上 … return str; // 将导致错误 }
要搞清楚返回的究竟是“值”、“指针”还是“引用”。
如果函数返回值是一个对象，要考虑 return 语句的效率。例如return String(s1 + s2);
6.4 其它建议
【建议 6-4-1】函数的功能要单一，不要设计多用途的函数。（但是可以将一个函数的功能拆的足够小，形成工具文件库）
【建议 6-4-2】函数体的规模要小，尽量控制在 50 行代码之内。
【建议 6-4-3】尽量避免函数带有“记忆”功能。相同的输入应当产生相同的输出。带有“记忆”功能的函数，其行为可能是不可预测的，因为它的行为可能取决于某种“记忆状态”。这样的函数既不易理解又不利于测试和维护。在 C/C++语言中，函数的 static 局部变量是函数的“记忆”存储器。建议尽量少用 static 局部变量，除非必需。
【建议 6-4-4】不仅要检查输入参数的有效性，还要检查通过其它途径进入函数体内的变量的有效性，例如全局变量、文件句柄等
【建议 6-4-5】用于出错处理的返回值一定要清楚，让使用者不容易忽视或误解错误情况。
6.5 使用断言
程序一般分为 Debug 版本和 Release 版本，Debug 版本用于内部调试，Release 版本发行给用户使用。
断言 assert 是仅在 Debug 版本起作用的宏，它用于检查“不应该”发生的情况。示例 6-5 是一个内存复制函数。在运行过程中，如果 assert 的参数为假，那么程序就会中止（一般地还会出现提示对话，说明在什么地方引发了 assert）。1
//复制不重叠的内存块 void *memcpy(void *pvTo, const void *pvFrom, size_t size) { assert((pvTo != NULL) && (pvFrom != NULL)); // 使用断言 byte *pbTo = (byte *) pvTo; // 防止改变 pvTo 的地址 byte *pbFrom = (byte *) pvFrom; // 防止改变 pvFrom 的地址 while(size -- > 0 ) *pbTo ++ = *pbFrom ++ ; return pvTo; }
【规则 6-5-1】使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别，后者是必然存在的并且是一定要作出处理的。
【规则 6-5-2】在函数的入口处，使用断言检查参数的有效性（合法性）
【建议 6-5-1】在编写函数时，要进行反复的考查，并且自问：“我打算做哪些假定？”一旦确定了的假定，就要使用断言对假定进行检查
【建议 6-5-2】一般教科书都鼓励程序员们进行防错设计，但要记住这种编程风格可能会隐瞒错误。当进行防错设计时，如果“不可能发生”的事情的确发生了，则要使用断言进行报警
6.6 引用与指针的比较
引用的一些规则如下：
（1）引用被创建的同时必须被初始化（指针则可以在任何时候被初始化）。
（2）不能有 NULL 引用，引用必须与合法的存储单元关联（指针则可以是 NULL）。
（3）一旦引用被初始化，就不能改变引用的关系（指针则可以随时改变所指的对象）。
对比上述三个示例程序，会发现“引用传递”的性质象“指针传递”，而书写方式
象“值传递”。实际上“引用”可以做的任何事情“指针”也都能够做，为什么还要“引用”这东西？
答案是“用适当的工具做恰如其分的工作”。
指针能够毫无约束地操作内存中的如何东西，尽管指针功能强大，但是非常危险。
就象一把刀，它可以用来砍树、裁纸、修指甲、理发等等，谁敢这样用？
如果的确只需要借用一下某个对象的“别名”，那么就用“引用”，而不要用“指针”，以免发生意外。
[服务器高级架构体系：https://xxetb.xet.tech/s/4DEnTI
assert 不是一个仓促拼凑起来的宏。为了不在程序的 Debug 版本和 Release 版本引起差别，assert 不应该产生任何副作用。所以 assert 不是函数，而是宏。程序员可以把assert 看成一个在任何系统状态下都可以安全使用的无害测试手段。如果程序在 assert处终止了，并不是说含有该 assert 的函数有错误，而是调用者出了差错，assert 可以帮助我们找到发生错误的原因。
很少有比跟踪到程序的断言，却不知道该断言的作用更让人沮丧的事了。
你化了很多时间，不是为了排除错误，而只是为了弄清楚这个错误到底是什么。
有的时候，程序员偶尔还会设计出有错误的断言。
所以如果搞不清楚断言检查的是什么，就很难判断错误是出现在程序中，还是出现在断言中。
幸运的是这个问题很好解决，只要加上清晰的注释即可。
这本是显而易见的事情，可是很少有程序员这样做。这好比一个人在森林里，看到树上钉着一块“危险”的大牌子。但危险到底是什么？树要倒？有废井？有野兽？
除非告诉人们“危险”是什么，否则这个警告牌难以起到积极有效的作用。难以理解的断言常常被程序员忽略，甚至被删除。 ↩︎
