代码缩进规范

代码缩进规范篇一：代码编写规范知识管理系统代码编写规范 一、介绍 本文档为知识管理系统代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了 Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments） 。我们不使用“文档注释”这样的说法，而会直接说 Javadoc。 其他“术语说明” ，将在文档中需要说明的地方单独说明。 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。 二、源码文件基础文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 文件编码：UTF-8 源码文件使用 UTF-8 编码。 特殊字符 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab 字符不被用作缩进控制。 特殊转义字符串 任何需要转义字符串表示的字符（例如b, t, n, f, r, “, 和等） ，采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如 012）或 Unicode 码（例如 u000a）表示。 非 ASCII 字符 对于其余非 ASCII 字符，直接使用 Unicode 字符（例如 ） ，或者对应的 Unicode 码（例如 u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。 注意：在使用 Unicode 码转义，或者甚至是有时直接使用 Unicode 字符的时候，添加一点说明注释将对别人读懂代码很有帮助。 三、源码文件结构源码文件按照先后顺序，由以下几部分组成： 1. license 或者 copyright 声明信息。 （如果需要声明） 2. 包（package）声明语句。 3. import 语句。 4. 类声明（每个源码文件只能有一个顶级类） 。 每个部分之间应该只有一行空行作为间隔。 license 或者 copyright 的声明信息。 如果需要声明 license 或 copyright 信息，应该在文件开始时声明。 包声明 包声明的行没有行长度的限制。单行长度限制不适用于包声明。 import 语句 不使用通配符 import 即，不要出现类似这样的 import 语句：import *; 没有行长度限制 import 语句的行没有行长度的限制。单行长度限制不适用于 import 语句所在行。 顺序和空行import 语句应该被分为几个组，每个组之间由单行的空行隔开。分组的顺序如下： 1. 所有的静态导入为归为一组。 2. （项目自带包）包的 import 归为一组。 3. 第三方包。每个顶级包归为一组。第三方包之间按 ASCII 码排序。例如：android, com, junit,org, sun 4. java 包归为一组。 5. javax 包归为一组。 同一组内的 import 语句之间不应用空行隔开。同一组中的 import 语句按 ASCII 码排序。 类声明 只声明一个顶级类 每个源码文件中只能有一个顶级类。 例外：，该文件中可没有 package-info 类。 类成员顺序 类成员的顺序对代码的易读性有很大影响，但这也不存在唯一的通用法则。不同的类可能有不同的排序方式。 重要的是，每个类都要按照一定的逻辑规律排序。维护者应该要能解释这种排序逻辑。比如，新的方法不能总是习惯性地添加到类的结尾，因为这样就是按时间顺序而非某种逻辑来排序的。 重载方法：不应该分开 当一个类有多个构造函数，或者多个同名成员方法时，这些函数应该写在一起，不应该被其他成员分开。四、格式 术语说明：块状结构（block-like construct）指类、成员函数和构造函数的实现部分（大括号中间部分） 。注意，在后面的节中讲到数组初始化，所有的数组初始化都可以被认为是一个块状结构（非强制） 。 大括号 大括号不可省略 大括号一般用在 if, else, for, do 和 while 等语句。即使当它的实现为空或者只有一句话时，也需要使用。 非空语句块采用 K catch(ProblemException e) 篇二：代码规范代码规范.txt 爱情是艺术，结婚是技术，离婚是算术。这年头女孩们都在争做小“腰”精，谁还稀罕小“腹”婆呀？高职不如高薪，高薪不如高寿，高寿不如高兴。 编程风格规范 (Ver ) 一、前言： 为了便于源程序的交流，减少合作开发中的障碍， Mental Studio 特制定了本规范。本规范的描述主要以 Borland C+ Builder 语言为例，对 Borland Delphi 的特别说明见附录一。 二、规范：以下对本规范作详细说明。 1源程序文件组织：每个程序文件单元通常都应由 .h文件和 .cpp 文件组成，并将单元的公共声明部分放在 .h 文件中。划分单元主要是以类为依据，原则上每个较大的类都应为一个单独的单元，但在类较小且多个小类关系密切等情况下也可几个类共一个单元（建议仅对已经详细测试的较为通用的类采用） 。 2源程序文件结构：每个程序文件应由标题、内容和附加说明三部分组成。 （1）标题：文件最前面的注释说明，其内容主要包括：程序名，作者，版权信息，简要说明等，必要时应有更详尽的说明（将以此部分以空行隔开单独注释） 。 （2）内容：为文件源代码部分基本上按预处理语句、类型定义、变量定义、函数原型、函数实现（仅对 .cpp 文件）的顺序。 main 、 winmain ，控件注册等函数应放在内容部分的最后，类的定义按 private 、 protected 、 pubilic 、 _pubished 的顺序，并尽量保持每一部分只有一个，各部分中按数据、函数、属性、事件的顺序。 （3）附加说明：文件末尾的补充说明，如参考资料等，若内容不多也可放在标题部分的最后。 3编辑风格： （1）缩进：缩进以 Tab 为单位，一个 Tab 为四个空格大小。预处理语句、全局数据、函数原型、标题、附加说明、函数说明、标号等均顶格书写。语句块的“” “”配对对齐，并与其前一行对齐，语句块类的语句缩进建议每个“” “”单独占一行。 （2）空格：数据和函数在其类型，修饰（如 _fastcall 等）名称之间适当空格并据情况对齐。关键字原则上空一格，如： if ( . ) 等，运算符的空格规定如下：“:” 、 “-”、 “”、 “”、 “+”、 “-”、 “”、 “!”、“+”、 “-”（指正负号） ， “&”（取址或引用） 、 “*”（指使用指针时）等几个运算符两边不空格（其中单目运算符系指与操作数相连的一边） ，其它运算符（包括大多数二目运算符和三目运算符“?:”两边均空一格， “(”、 “)”运算符在其内侧空一格，在作函数定义时还可据情况多空或不空格来对齐，但在函数实现时可以不用。 “,”运算符只在其后空一格，需对齐时也可不空或多空格， “sizeof”运算符建议也在其后空一格，不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。 （3）对齐：原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在“,”处或运算符处，换行后最好以运算符打头，并且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下一行为“”应与首行对齐。 （4）空行：程序文件结构各部分之间空两行，若不必要也可只空一行，各函数实现之间一般空两行，由于 BCB会自动产生一行“/-”做分隔，另因每个函数还要有函数说明注释，故通常只需空一行或不空，但对于没有函数说明的情况至少应再空一行。对自己写的函数，建议也加上“/-”做分隔。函数内部数据与代码之间应空至少一行，代码中适当处应以空行空开，建议在代码中出现变量声明时，在其前空一行。类中四个“p”之间至 少空一行，在其中的数据与函数之间也应空行。（5）注释：对注释有以下三点要求： A.必须是有意义； B.必须正确的描述了程序； C.必须是最新的。 注释必不可少，但也不应过多，以下是四种必要的注释： A.标题、附加说明； B.函数说明：对几乎每个函数都应有适当的说明，通常加在函数实现之前，在没有函数实现部分的情况下则加在函数原型前，其内容主要是函数的功能、目的、算法等说明，参数说明、返回值说明等，必要时还要有一些如特别的软硬件要求等说明； C.在代码不明晰或不可移植处应有少量说明； D.及少量的其它注释。 注释有块注释和行注释两种，分别是指：“/*/”和“/”建议对 A 用块注释，D 用行注释， B、C 则视情况而定，但应统一，至少在一个单元中 B类注释形式应统一。 4 命名规范：坚持采用匈牙利变量命名惯例，类型名称按 Borland 惯例用“T”做前缀，参数的命(来自: 小 龙 文档网:代码缩进规范)名统一以小写“a”前缀，所有标识符一律用英文或英文缩写，杜绝采用拼音，标识符中每个单词首字母大写，缩写词汇一般全部大写，只在必要时加“_”间隔词汇，用 #define 定义的宏一般全部大写，其它具体细节待定。 三、补充说明：本规范历史： 1996 年 8 月 口头版 1997 年 11 月 20 日 版 1999 年 7 月 1 日 版 XX 年 12 月 16 日 修订版 附录一 对 Borland Delphi 的补充说明： 虽然 Delphi 是大小写无关的，但建议仍按大小写有关的方式编程，保持标识符的大小写一致，对于关键字的大小写可采用全部小写，全部大写或首字母大写等方式，但必须保持统一。 Delphi 支持多种多种块注释方式，建议采用“(* . *)”的方式，以和编译指令“$ . ”及和 C/C+ 有所区别。 附录二 匈牙利命名法(Hungarian-Notation)： 据说这种命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的，后来他在微软呆了几年，于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在，大部分程序员不管自己使用什么软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把量名变按：属性+类型+对象 描述的顺序组合起来，以使程序员操作变量时对变量的类型和其它属性有直观的了解，下面是 HN 变量命名规范，其中也有一些是我个人的偏向： 属性部分 全局变量 g_常量 c_ c+类成员变量 m_ 静态变量 s_ 类型部分 指针 p 函数 fn 无效 v 句柄 h 长整型 l 布尔 b 浮点型（有时也指文件） f 双字 dw 字符串 sz 短整型 n 双精度浮点 d 计数 c（通常用 cnt） 字符 ch（通常用 c） 整型 i（通常用 n） 字节 by 字 w 实型 r 无符号 u 描述部分 最大 Max 最小 Min 初始化 Init 临时变量 T（或 Temp） 源对象 Src 目的对象 Dest 这里顺便写几个例子： hwnd ： h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄； pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示指向 EatApple 函数的函数指针变量。 g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。 上面就是 HN 命名法的一般规则。附录三 其它的编程风格规范（供参考）： 在软件编程过程中，如果每个程序员都按自己的习惯和风格编写程序，这种因人而异的程序风格势必降低程序的可读性，对软件的测试、交流、重用以及软件的维护产生极为不利的影响。为了解决这个问题，最终提高开发效率，必须执行本规范。 本规范在编程基本风格、可读性、结构化、正确性与容错性、可重用性等方面提出了要求，它是程序员编程素质的综合体现。 程序员的编程水平编程规范编程效率。 1.基本要求 程序结构清析，简单易懂，单个函数的程序行数不得超过 100 行。 打算干什么，要简单，直接了当，代码精简，避免垃圾程序。 尽量使用标准库函数和公共函数。 不要随意定义全局变量，尽量使用局部变量。 使用括号以避免二义性。 2.可读性要求 可读性第一，效率第二。 保持注释与代码完全一致。 每个源程序文件，都有文件头说明，说明规格见规范。每个函数，都有函数头说明，说明规格见规范。 主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。 常量定义（DEFINE）有相应说明。 处理过程的每个阶段都有相关注释说明。 在典型算法前都有注释。 利用缩进来显示程序的逻辑结构，缩进量一致并以 Tab 键为单位，定义 Tab 为 6 个字节。 循环、分支层次不要超过五层。 注释可以与语句在同一行，也可以在上行。 空行和空白字符也是一种特殊注释。 一目了然的语句不加注释。 注释的作用范围可以为：定义、引用、条件分支以及一段代码。 注释行数（不包括程序头和函数头说明部分）应占总行数的 1/5 到 1/3 。 3.结构化要求 禁止出现两条等价的支路。 禁止 GOTO 语句。 用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。 用 CASE 实现多路分支。 避免从循环引出多个出口。 函数只有一个出口。不使用条件赋值语句。 避免不必要的分支。 不要轻易用条件分支去替换逻辑表达式。 4.正确性与容错性要求 程序首先是正确，其次是优美 无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。 改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。 所有变量在调用前必须被初始化。 对所有的用户输入，必须进行合法性检查。 不要比较浮点数的相等， 如： * = ， 不可靠 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。 单元测试也是编程的一部分，提交联调测试的程序必须通过单元测试。 5.可重用性要求 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。 公共控件或类应考虑 OO 思想，减少外界联系，考虑独立性或封装性。 公共控件或类应建立使用模板。 篇三：代码规范格式规范 对于代码，首要要求是它必须正确，能够按照设计预定功能去运行； 第二是要求代码必须清晰易懂，使软件开发团队中的程序员能够容易地理解代码。代码的组织和风格的基本原则是：便于自己的开发，易于与他人的交流。因个人习惯和编辑器等可以设置和形成自己的风格，但必须前后一致，并符合本规范的基本要求和原则。 1.缩进 使用 TAB 缩进，而不是空格键将缩进 2，4，8 字符的选择权留给阅读者。 子功能块当在其父功能块后缩进。当功能块过多而导致缩进过深时当将子功能块提取出