C与C 作用域引申出的编码规范.pdf

C/C++作用域引申出的编码规范 编码规范非常重要，不仅仅在于没有了它在团体合作中互相读不懂对方的代码，还在于以后 的自己也可能需要维护以前自己写的代码，还在于可读性越强越不容易犯一些常规错误。 规范本身应该是一个规定，但C/C++在编码上并没有这样的规定，凡符合C/C++语 法的就是合格的代码，但符合C/C++语法的代码不一定是优秀的代码，要对一些不良行为做 约定，比如不应该将局部使用的变量作为全局变量，这是其一；其二，代码本身也可能会进 行合作开发或后期维护，那么一个表达统一结构清晰的代码是必要的。由这两点产生了编码 规范，所以编码规范就是公司或团体对代码编写的一个规定和约定。 对于第二点而言，虽然其存在的价值是必须的，但是适用场合都有所不同性，且众 口难调，缺乏非此不可的科学依据。比如大家熟悉的匈牙利命名法，其在变量名称中包含了 类型信息，其优点不言而喻，在代码实现过程中非常方便，但缺点也有不少，比如 变量本 身就具有类型，而名称中再次包含了类型信息，这是严重的冗余，修改变量类型就必须修改 变量名称，更主要的是没有办法保证它们的一致性，总之 名称应该是对功能的描述，而不 应该含有类型信息。所以即使强如匈牙利命名法，在M$的编码规范中也不将再存在。因为 第二点不能放之四海而皆准，所以我将在这篇短文中讲述第一点，有科学依据则易于为人接 受，但我还是要强调一下，这第一点只是编码规范存在理由的一部分，而不是全部，第二个 理由也非常重要，其引申出来的规范不可缺少。 要想写出优秀的C/C++代码有很多注意点，不是一个小短文可以描述清楚的，我这 里仅仅讲述变量的作用域和生存期，根据这些规则产生的编码规范会和你曾经见到过的一些 编码规范有所抵触，这不足为奇，比如很多编码规范规定了函数体的最大行数，过多的行数 大部分情况下是因为功能结构化分不清，不利于阅读，但却不一定如此，如果在这个规定和 规定这个规定的目的之间产生了抵触，那么这时就应该舍弃这个规定，所以我认为称它编码 建议胜于称它编码规范。 对于编码规范含义的讲解至此结束，话入正题，对于一个面向过程的语言而言，函 数过程是其基本单位，函数是一个功能完整的实现过程，面向对象也如此，只是类代替了函 数过程的部分地位。 为什么要将一个过程独立成一个函数？这是因为此过程功能完整明确，在独立成一 个函数之后其还具备了复用的能力。 为什么不将一个过程独立成一个函数？这是因为此过程与其他部分耦合度太高，没 有明确的功能含义，即使独立出来，也不存在可复用的场合。 作用域就是起作用的范围，一个应该在多处起作用的对象，不应该局限于一个小空 间中，反之亦然。这里可以使用的有 函数、对象、名字空间 等，假如以上皆不符合，那么 就应该使用为部分人所忽视的“{}”。 以下就是一个对变量/过程的作用域和生存期的演示： 在很多地方都可能会用到的函数或类型() { }; 一个功能函数或类型() { 仅在此函数或类型中用到且多次用到的子函数或子类型() // C++没有子函数这一说 法，可以使用函数对象（仿函数）替代 { }; 在接下来的部分也需要用到的变量; // 注意这个分号 { 仅在这个{}中用到的临时变量; 仅在此函数或类型中用到且只用到一次的功能段 } 函数或类型其他部分; }; 这样就将变量和过程局限在它们应有的空间中，避免了变量和过程对以后的变量和 过程的污染，尤其在代码量很大的程序中，而且因为有了{}区分不同的功能代码，使得程序 可读性增强。当然一切还是了可读性，看以下这个情况： 某个功能代码的第一行; 某个功能代码的第二行; 某个功能代码的第三行; { 只为此功能实现一次的，由与此功能无逻辑关系的代码第一行; 第二行; …… ; 第 n行; } 某个功能代码的第四行; 某个功能代码的第五行; 某个功能代码的第六行; 这样实现也许逻辑清晰，但在代码编辑器中需要非常麻烦的上下翻页才能看到连续 的功能代码，而且{}中的代码太长，像个丑陋的补丁，这时候将{}中的