c代码编写规范pdfWord下载.docx

c代码编写规范pdfWord下载.docx

《c代码编写规范pdfWord下载.docx》由会员分享，可在线阅读，更多相关《c代码编写规范pdfWord下载.docx（12页珍藏版）》请在冰豆网上搜索。

　　impact:

　　maincontent（Functionname、parameters、returns）

　　******************************************************/

　　3.3模块（类）注释

　　模块开始建议使用以下形式书写模块注释：

　　///

　　///moduleid：

　　///depiction：

　　///author：

作者中文名

　　///createdate：

　　如果模块只进行部分少量代码的修改时，则每次修改须添加以下注释：

　　///Rewriter：

Rewritedate：

start1：

/*原代码内容*/

　　///end1：

　　将原代码内容注释掉，然后添加新代码使用以下注释：

　　///addedby：

adddate：

start2：

新代码内容

　　///end2：

　　如果模块输入输出参数或功能结构有较大修改，则每次修改必须添加以下注释：

　　///logid：

　　///writer：

修改者中文名

　　///Rewritedate：

　　3.4类属性注释

　　在类的属性必须以以下格式编写属性注释：

　　///　　

　　3.5方法注释

　　在类的方法声明前必须以以下格式编写注释

　　///　　"

>

　　3.6代码间注释

　　代码间注释分为单行注释和多行注释：

　　单行注释：

　　//

　　多行注释：

　　/*多行注释1

　　多行注释2

　　多行注释3*/

　　代码中遇到语句块时必须添加注释（if,for,foreach,）,添加的注释必须能够说明此语句块的作用和实现手段（所用算法等等）。

　　4命名总体规则

　　名字应该能够标识事物的特性。

　　名字一律使用英文单词，而不能为拼音。

　　名字尽量不使用缩写，除非它是众所周知的。

　　名字可以有两个或三个单词组成，但不应多于三个，控制在3至30个字母以内。

　　在名字中，多个单词用大写第一个字母（其它字母小写）来分隔。

例如：

issuperuser。

名字尽量使用前缀而不是后缀。

　　名字中的单词尽量使用名词，如有动词，也尽量放在后面。

Functionuserdelete（而不是Functiondeleteuser）。

　　文件名一般以类名一致，切遵循类命定义规则，及大小写规范。

　　在具体任务开发中，如果有特定的命名约定，则在相应的软件开发计划中予以明确定义及上报质量管理部审计组。

　　5命名规范

　　5.1变量（Variable）命名

　　a）程序文件（*.cs）中的变量命名

　　所有变量如果无前缀必须首字母小写，前缀无特殊要求，但必须是易于识别公认的做法，如’m_’‘_’,切毋自创缩写

　　鉴于大多数名称都是通过连接若干单词构造的，必须使用大小写混合的格式以简化它们的阅读。

每个单词的第一个字母都是大写.

　　即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。

仅对于短循环索引使用单字母变量名，如i或j。

　　在变量名中使用互补对，如min/max、begin/end和open/close。

　　不要使用原义数字或原义字符串，如For（i=1;

i　　b）控件命名

　　控件命名=web控件缩写前缀+[“_”]+名称

　　如：

datagriddg_userlist或dguserlist

　　5.2常量命名

　　常量名也应当有一定的意义，格式为noun或noun_VeRb。

常量名均为大写，字之间用下划线分隔。

　　例：

　　privateconstboolweb_enablepagecache_deFault=true;

privateconstintweb_pagecacheexpiResinseconds_deFault=3600;

privateconstboolweb_enablessl_deFault=false;

注：

　　变量名和常量名最多可以包含255个字符，但是，超过25到30个字符的名称比较笨拙。

此外，要想取一个有实际意义的名称，清楚地表达变量或常量的用途，25或30个字符应当足够了。

　　5.3类（class）命名

　　a）名字应该能够标识事物的特性。

　　b）名字尽量不使用缩写，除非它是众所周知的。

　　c）名字可以有两个或三个单词组成，但通常不应多于三个。

　　d）在名字中，所有单词第一个字母大写。

例如issuperuser，包含id的，id可以全部大写，如customerid。

　　e）使用名词或名词短语命名类。

　　f）少用缩写。

　　g）不要使用下划线字符（_）。

publicclassFilestream

　　publicclassbutton

　　publicclassstring

　　5.4接口（interface）命名

　　和类命名规范相同，唯一区别是接口在名字前加上“i”前缀

　　interfaceidbcommand;

　　interfaceibutton;

　　5.5方法（me（c,,,代码编写规范,pdf）thod）命名

　　和类命名规范相同。

　　5.6命名空间（namespace）命名

　　5.7属性（property）命名

　　与类名命名规范相同。

　　6编码规则

　　6.1错误检查规则

　　a）编程中要考虑函数的各种执行情况，尽可能处理所有流程情况。

　　b）检查所有的系统调用的错误信息，除非要忽略错误。

　　c）将函数分两类：

一类为与屏幕的显示无关，另一类与屏幕的显示有关。

对于与屏幕显示无关的函数，函数通过返回值来报告错误。

对于与屏幕显示有关的函数，函数要负责向用户发出警告，并进行错误处理。

　　d）错误处理代码一般放在函数末尾。

　　e）对于通用的错误处理，可建立通用的错误处理函数，处理常见的通用的错误。

　　6.2大括号规则

　　将大括号放置在关键词下方的同列处，例如：

　　if（$condition）while（$condition）

　　{{

　　......

　　}}

　　6.3缩进规则

　　使用一个“tab”为每层次缩进。

　　functionfunc（）

　　{

　　if（somethingbad）

　　if（anotherthingbad）

　　while（moreinput）

　　}

　　6.4小括号规则

　　a）不要把小括号和关键词（if、while等）紧贴在一起，要用空格隔开它们。

　　b）不要把小括号和函数名紧贴在一起。

　　c）除非必要，不要在Return返回语句中使用小括号。

因为关键字不是函数，如果小括号紧贴着函数名和关键字，二者很容易被看成是一体的。

　　6.5ifthenelse规则

　　如果你有用到elseif语句的话，通常最好有一个else块以用于处理未处理到的其他情况。

可以的话放一个记录信息注释在else处，即使在else没有任何的动作。

其格式为：

　　if（条件1）//注释

　　elseif（条件2）//注释

　　else//注释

　　注：

if和循环的嵌套最多允许4层

　　6.6比较规则

　　总是将恒量放在等号/不等号的左边。

一个原因是假如你在等式中漏了一个等号，语法检查器会为你报错。

第二个原因是你能立刻找到数值而不是在你的表达式的末端找到它。

if（6==$errornum）...

　　6.7case规则

　　defaultcase总应该存在，如果不允许到达，则应该保证：

若到达了就会触发一个错误。

case的选择条件最好使用int或string类型。

　　篇二：

google-c++编程规范（完整）

　　背景google的开源项目大多使用c++开发。

每一个c++程序员也都知道，c++具有很多强大的语言特性，但这种强大不可避免的导致它的复杂，这种复杂会使得代码更易于出现bug、难于阅读和维护。

　　本指南的目的是通过详细阐述在c++编码时要怎样写、不要怎样写来规避其复杂性。

这些规则可在允许代码有效使用c++语言特性的同时使其易于管理。

　　风格，也被视为可读性，主要指称管理c++代码的习惯。

使用术语风格有点用词不当，因为这些习惯远不止源代码文件格式这么简单。

　　使代码易于管理的方法之一是增强代码一致性，让别人可以读懂你的代码是很重要的，保持统一编程风格意味着可以轻松根据“模式匹配”规则推断各种符号的含义。

创建通用的、必需的习惯用语和模式可以使代码更加容易理解，在某些情况下改变一些编程风格可能会是好的选择，但我们还是应该遵循一致性原则，尽量不这样去做。

　　本指南的另一个观点是c++特性的臃肿。

c++是一门包含大量高级特性的巨型语言，某些情况下，我们会限制甚至禁止使用某些特性使代码简化，避免可能导致的各种问题，指南中列举了这类特性，并解释说为什么这些特性是被限制使用的。

　　由google开发的开源项目将遵照本指南约定。

　　注意：

本指南并非c++教程，我们假定读者已经对c++非常熟悉。

　　头文件

　　通常，每一个.cc文件（c++的源文件）都有一个对应的.h文件（头文件），也有一些例外，如单元测试代码和只包含main（）的.cc文件。

　　正确使用头文件可令代码在可读性、文件大小和性能上大为改观。

　　下面的规则将引导你规避使用头文件时的各种麻烦。

　　1.#define的保护

　　所有头文件都应该使用#define防止头文件被多重包含（multipleinclusion），命名格式当是：

　　_　　__h_

　　为保证唯一性，头文件的命名应基于其所在项目源代码树的全路径。

例如，项目foo中的头文件foo/src/bar/baz.h按如下方式保护：

　　#ifndefFoo_baR_baz_h_

　　#defineFoo_baR_baz_h_

　　...

　　#endif//Foo_baR_baz_h_

　　1

　　2.头文件依赖

　　使用前置声明（forwarddeclarations）尽量减少.h文件中#include的数量。

　　当一个头文件被包含的同时也引入了一项新的依赖（dependency），只要该头文件被修改，代码就要重新编译。

如果你的头文件包含了其他头文件，这些头文件的任何改变也将导致那些包含了你的头文件的代码重新编译。

因此，我们宁可尽量少包含头文件，尤其是那些包含在其他头文件中的。

　　使用前置声明可以显著减少需要包含的头文件数量。

举例说明：

头文件中用到类File，但不需要访问File的声明，则头文件中只需前置声明classFile;

无需#include"

file/base/file.h"

。

　　在头文件如何做到使用类Foo而无需访问类的定义？

　　1）将数据成员类型声明为Foo*或Foo//经常使用的符号

　　boolateof（）{returnpos_==eoF;

}//使用本命名空间内的符号eoF

　　}//namespace

　　然而，与特定类关联的文件作用域声明在该类中被声明为类型、静态数据成员或静态成员函数，而不是不具名命名空间的成员。

像上文展示的那样，不具名命名空间结束时用注释//5

　　篇三：

c_代码编写规范

　　1.前言

　　1.1.文档目的

　　本文档主要提供公司内部用c#语言进行编程时的编码标准，这个标准能帮助程序开发人员更好地进行产品开发，避免陷阱，还可以方便开发团队内部的交流。

　　本文档的主要读者是公司全体开发人员。

1.2文档范围

　　本文档仅包含c#语言的编码标准。

　　2.命名约定和风格

　　1）定义类型、方法名、属性名和常量使用pascal命名规范。

pascal方式：

所有单词第一个字母大写，其他字母小写。

publicclasssomeclass{

　　constintdefaultsize=100;

publicvoidsomemethod（）{}}

　　2）定义局部变量和方法的参数使用camel命名规范。

camel方式：

除第一个单词外，单词第一个字母大写，其他字母小写。

intmynumberValue；

　　voidmymethod（intmyparamValue）{}

　　3）接口的名称前加上i。

interfaceimyinterface{}

　　4）在私有（private）字段成员变量前面加上m_。

publicclasssomeclass.{

　　privateintm_userid;

　　privatestringm_username；

}

　　5）所有字段成员变量应该定义在前面，和属性或方法间空开一行。

publicclassmyclass.{

.

　　privatestringm_username;

　　publicvoidsomemethod1（）.{…}

　　publicvoidsomemethod2（）{…}

　　6）局部变量的定尽可能靠近它的初次使用，尤其是临时循环变量。

7）命名方法时采用“动词-对象”对，例如showdialog（）。

　　8）有返回值的方法应该取名表示其返回值，例如getobjectstate（）。

9）采用描述性的变量名。

　　●除非在循环中使用的临时循环变量，就避免采用单字母的变量名，如i或t,而是采用index或temp。

　　●对public和protected成员避免采用匈牙利命名法，就采用pascal命名规范。

●不要采用缩写（例如将number缩写为num）。

　　10）常用控件或对象的取名，采用使用匈牙利命名法，即使用控件类型（小写两个或三个字符）作为前缀。

　　●采用object不用object●采用string不用string●采用int不用int32。

　　12）对于泛型，类型采用大写字母。

当处理.net类型type时保留后缀type。

//正确：

　　publicclasslinkedlist//避免使用：

　　publicclasslinkedlist

　　13）自定义属性类型名采用attribute作为后缀。

14）自定义异常类型名采用exception作为后缀。

15）文件名应该体现其包含的类，通常与类名相同。

　　定义hy.Fc.dbutility类的文件名是dbutility.cs

　　16）当使用partial类型且每部分分配一个文件时，以类型名加p和序数命名每个文件。

//inmyclassp1.cs

　　publicpartialclassmyclass{…}

　　//inmyclassp2.cs

　　17）采用有意义的自定义命名空间名，格式为公司名称（hy）+产品名称+类库名称。

usinghy.Fc.dbutility;

usinghy.pems.app;

usingsdpw.lbt.utility;

　　18）避免使用类的全称，而是采用using语句。

19）避免在命名空间内使用using语句。

　　20）将所有Framework命名空间名放在一起，后面放自定义或第三方的命名空间名。

usingsystem;

usingsystem.data;

usingmycompany;

usingmycontrols;

　　21）严格遵守缩进格式，使用标准的tab缩进。

22）注释缩进和其注释的代码在同一层次。

　　23）对类的全部公共成员采用标准的xml方式编写注释。

　　24）左大括号“{”总是放在新行中。

if语句总是使用括号，即使它包含一句语句。

25）采用委托推断，不要显式实例化委托。

　　delegatevoidsomedelegate（）;

　　publicvoidsomemethod（）{…}

　　somedelegatesomedelegate=somemethod;

　　26）匿名方法模仿普通方法的布局，和匿名委托定义放在一行。

遵守将左大括号放在新行的

　　规则。

　　publicvoidinvokemethod（）{

　　somedelegatesomedelegate=delegate（stringname）

　　messagebox.show（name）;

};

　　somedelegate（"

juval"

）;

　　//避免采用：

　　somedelegatesomedelegate=

　　delegate（stringname）{messagebox.show（name）;

somedelegate（"

　　27）没有参数的匿名方法使用空括号。

仅当匿名方法可能被用于任何委托时省略括号。

　　//正确

　　somedelegatesomedelegate1=delegate（）

　　messagebox.show（"

hello"

　　somedelegatesomedelegate1=delegate

　　3.编码实践

　　1）避免在一个文件中放多个类。

　　2）一个文件应该只对一个命名空间提供类型。

避免在同一文件中有多个命名空间。

3）避免文件长度超过2000行（除了机器自动产生的代码）。

4）避免方法定义超过100行。

　　5）避免超过5个参数的方法。

使用结构传递多个参数。

6）每行应该不超过80个字符。

　　7）不要手工编辑任何机器生成的代码。

　　●如果修改机器生成的代码，修改代码格式和风格以符合本编码标准。

●尺可能采用partial类以分解出需要维护的部分。

　　8）避免对显而易见的内容作注释。

代码应该是自解释的。

由可读性强的变量和方法组成的好的代码应该不需要注释。

　　9）对操作的前提、内在算法等必须编写注释或写文档。

10）对类的全部公共成员采用标准的xml方式编写注释。

11）决不要硬编码数值，而总是声明一个常量。

　　12）仅对本来就是常量的值使用const修饰符，例如一周的天数。

　　13）避免对只读变量使用const修饰符。

在此情况下，采用readonly修饰符。

　　publicclassmyclass{

　　publicreadonlyintnumber;

publicmyclass（intsomeValue）{

　　number=someValue;

　　publicconstintdaysinweek=7;

　　15）每行代码应该经过白盒测试。

16）仅捕获已经显式处理了的异常。

　　17）在抛出异常的catch语句中，总是抛出异常以保持最初错误的堆栈位置。

　　catch（exceptionexception）{

　　messagebox.show（exception.message）;

throw;

//sameasthrowexception;

　　18）避免将错误代码作为方法的返回值。

19）避免定义自定义的异常类。

20）定义自定义异常时：

　　●从applicationexception继承●提供自定义的序列化。

　　21）避免在一个程序集中有多个main（）方法。

　　22）仅对最需要的类型标记为public，其他的标记为internal。

23）避免采用friend程序集，因为这样增加了程序集间的耦合度。

24）避免使用依赖于从特定位置运行的程序集的代码。

　　25）尽量减少应用程序集（客户端exe程序集）的代码。

采用类库包含业务逻辑层代码。

26）避免对枚举提供明确的值。

//正确

　　publicenumcolor

　　Red,green,blue}

　　//避免

　　publicenumcolor{

　　Red=1,green=2,blue=3}

　　27）避免对枚举指定类型。

//避免

　　publicenumcolor:

long

　　28）if语句总是使用括号，即使它包含一句语句。

29）避免使用:

条件算符。

　　30）避免在布尔条件语句中调用函数。

赋值到局部变量并检查它们的值。

booliseverythingok（）

　　{...}//避免：

　　if（iseverythingok（））{...}//正确：

　　boolok=iseverythingok（）;

　　if（ok）{...}

　　31）总是使用从0开始的数组。

　　32）总是使用一个for循环显式地初始化一个引用类型的数组。

publicclassmyclass

　　{}