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