代码风格规范
本篇规范是PSR-1基本代码规范的继承与扩展。
本规范希望通过制定一系列规范化PHP代码的规则，以减少在浏览不同作者的代码时，因代码风格的不同而造成不便。
当多名程序员在多个项目中合作时，就需要一个共同的编码规范，而本文中的风格规范源自于多个不同项目代码风格的共同特性，因此，本规范的价值在于我们都遵循这个编码风格，而不是在于它本身。
关键词“必须”("MUST")、“一定不可/一定不能”("MUST NOT")、“需
要”("REQUIRED")、“将会”("SHALL")、“不会”("SHALL NOT")、“应该”("SHOULD")、“不该”("SHOULD NOT")、“推荐”("RECOMMENDED")、“可以”("MAY")和”可选“("OPTIONAL")的详细描述可参见RFC 2119。
1. 概览
?代码必须遵循PSR-1中的编码规范。
?代码必须使用4个空格符而不是tab键进行缩进。
?每行的字符数应该软性保持在80个之内，理论上一定不可多于120个，但一定不能有硬性限制。
?每个namespace命名空间声明语句和use声明语句块后面，必须插入一个空白行。
?类的开始花括号({)必须写在其声明后自成一行，结束花括号(})也必须写在其主体后自成一行。
?方法的开始花括号({)必须写在函数声明后自成一行，结束花括号(})也必须写在函数主体后自成一行。
?类的属性和方法必须添加访问修饰符（private、protected以
及public），abstract以及final必须声明在访问修饰符之前，
而static必须声明在访问修饰符之后。
?控制结构的关键字后必须要有一个空格符，而调用方法或函数时则一定不能有。
?控制结构的开始花括号({)必须写在声明的同一行，而结束花括号(})必须写在主体后自成一行。
?控制结构的开始左括号后和结束右括号前，都一定不能有空格符。1.1. 例子
以下例子程序简单地展示了以上大部分规范：
namespace Vendor\Package;
use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;
class Foo extends Bar implements FooInterface
{
publicfunction sampleFunction($a, $b =null)
{
if ($a === $b) {
bar();
} elseif ($a > $b) {
$foo->bar($arg1);
} else {
BazClass::bar($arg2, $arg3);
}
}
finalpublicstaticfunction bar()
{
// method body
}
}
2. 通则
2.1 基本编码准则
代码必须符合PSR-1中的所有规范。
2.2 文件
所有PHP文件必须使用Unix LF (linefeed)作为行的结束符。
所有PHP文件必须以一个空白行作为结束。
纯PHP代码文件必须省略最后的?>结束标签。
2.3. 行
行的长度一定不能有硬性的约束。
软性的长度约束一定要限制在120个字符以内，若超过此长度，带代码规范检查的编辑器一定要发出警告，不过一定不可发出错误提示。
每行不应该多于80个字符，大于80字符的行应该折成多行。
非空行后一定不能有多余的空格符。
空行可以使得阅读代码更加方便以及有助于代码的分块。
每行一定不能存在多于一条语句。
2.4. 缩进
代码必须使用4个空格符的缩进，一定不能用tab键。
备注: 使用空格而不是tab键缩进的好处在于，避免在比较代码差异、打补丁、重阅代码以及注释时产生混淆。并且，使用空格缩进，让对齐变得更方便。
2.5. 关键字以及True/False/Null
PHP所有关键字必须全部小写。
常量true、false和null也必须全部小写。
3. namespace 以及use 声明
namespace声明后必须插入一个空白行。
所有use必须在namespace后声明。
每条use声明语句必须只有一个use关键词。
use声明语句块后必须要有一个空白行。
例如：
namespace Vendor\Package;
use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;
// ... additional PHP code ...
4. 类、属性和方法
此处的“类”泛指所有的class类、接口以及traits可复用代码块。
4.1. 扩展与继承
关键词extends和implements必须写在类名称的同一行。
类的开始花括号必须独占一行，结束花括号也必须在类主体后独占一行。
namespace Vendor\Package;
use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;
class ClassName extends ParentClass implements\ArrayAccess, \Countable
{
// constants, properties, methods
}
implements的继承列表也可以分成多行，这样的话，每个继承接口名称都必须分开独立成行，包括第一个。
namespace Vendor\Package;
use FooClass;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;
class ClassName extends ParentClass implements
\ArrayAccess,
\Countable,
\Serializable
{
// constants, properties, methods
}
4.2. 属性
每个属性都必须添加访问修饰符。
一定不可使用关键字var声明一个属性。
每条语句一定不可定义超过一个属性。
不要使用下划线作为前缀，来区分属性是protected 或private。
以下是属性声明的一个范例：
namespace Vendor\Package;
class ClassName
{
public $foo =null;
}
4.3. 方法
所有方法都必须添加访问修饰符。
不要使用下划线作为前缀，来区分方法是protected 或private。
方法名称后一定不能有空格符，其开始花括号必须独占一行，结束花括号也必须在方法主体后单独成一行。参数左括号后和右括号前一定不能有空格。
一个标准的方法声明可参照以下范例，留意其括号、逗号、空格以及花括号的位置。
namespace Vendor\Package;
class ClassName
{
publicfunction fooBarBaz($arg1, &$arg2, $arg3 = [])
{
// method body
}
}
4.4. 方法的参数
参数列表中，每个逗号后面必须要有一个空格，而逗号前面一定不能有空格。
有默认值的参数，必须放到参数列表的末尾。
namespace Vendor\Package;
class ClassName
{
publicfunction foo($arg1, &$arg2, $arg3 = [])
{
// method body
}
}
参数列表可以分列成多行，这样，包括第一个参数在内的每个参数都必须单独成行。
拆分成多行的参数列表后，结束括号以及方法开始花括号必须写在同一行，中间用一个空格分隔。
namespace Vendor\Package;
class ClassName
{
publicfunction aVeryLongMethodName(
ClassTypeHint $arg1,
&$arg2,
array $arg3 = []
) {
// method body
}
}
4.5. abstract、final、以及static
需要添加abstract或final声明时，必须写在访问修饰符前，而static则必须
写在其后。
namespace Vendor\Package;
abstractclass ClassName
{
protectedstatic $foo;
abstractprotectedfunction zim();
finalpublicstaticfunction bar()
{
// method body
}
}
4.6. 方法及函数调用
方法及函数调用时，方法名或函数名与参数左括号之间一定不能有空格，参数右括号前也一定不能有空格。每个逗号前一定不能有空格，但其后必须有一个空格。
bar();
$foo->bar($arg1);
Foo::bar($arg2, $arg3);
参数可以分列成多行，此时包括第一个参数在内的每个参数都必须单独成行。
$foo->bar(
$longArgument,
$longerArgument,
$muchLongerArgument
);
5. 控制结构
控制结构的基本规范如下：
?控制结构关键词后必须有一个空格。
?左括号(后一定不能有空格。
?右括号)前也一定不能有空格。
?右括号)与开始花括号{间一定有一个空格。
?结构体主体一定要有一次缩进。
?结束花括号}一定在结构体主体后单独成行。
每个结构体的主体都必须被包含在成对的花括号之中，这能让结构体更加结构话，以及减少加入新行时，出错的可能性。
5.1. if、elseif和else
标准的if结构如下代码所示，留意括号、空格以及花括号的位置，注
意else和elseif都与前面的结束花括号在同一行。
if ($expr1) {
// if body
} elseif ($expr2) {
// elseif body
} else {
// else body;
}
应该使用关键词elseif代替所有else if，以使得所有的控制关键字都像是单独的一个词。
5.2. switch和case
标准的switch结构如下代码所示，留意括号、空格以及花括号的位置。case语句必须相对switch进行一次缩进，而break语句以及case内的其它语句都必须相对case进行一次缩进。如果存在非空的case直穿语句，主体里必须有类似//
no break的注释。
switch ($expr) {
case0:
echo'First case, with a break';
break;
case1:
echo'Second case, which falls through';
// no break
case2:
case3:
case4:
echo'Third case, return instead of break';
return;
default:
echo'Default case';
break;
}
5.3. while和do while
一个规范的while语句应该如下所示，注意其括号、空格以及花括号的位置。
while ($expr) {
// structure body
}
标准的do while语句如下所示，同样的，注意其括号、空格以及花括号的位置。
do {
// structure body;
} while ($expr);
5.4. for
标准的for语句如下所示，注意其括号、空格以及花括号的位置。
for ($i=0; $i<10; $i++) {
// for body
}
5.5. foreach
标准的foreach语句如下所示，注意其括号、空格以及花括号的位置。
foreach ($iterable as $key => $value) {
// foreach body
}
5.6. try, catch
标准的try catch语句如下所示，注意其括号、空格以及花括号的位置。
try {
// try body
} catch (FirstExceptionType $e) {
// catch body
} catch (OtherExceptionType $e) {
// catch body
}
6. 闭包
闭包声明时，关键词function后以及关键词use的前后都必须要有一个空格。开始花括号必须写在声明的同一行，结束花括号必须紧跟主体结束的下一行。
参数列表和变量列表的左括号后以及右括号前，必须不能有空格。
参数和变量列表中，逗号前必须不能有空格，而逗号后必须要有空格。
闭包中有默认值的参数必须放到列表的后面。
标准的闭包声明语句如下所示，注意其括号、逗号、空格以及花括号的位置。
$closureWithArgs=function ($arg1, $arg2) {
// body
};
$closureWithArgsAndVars=function ($arg1, $arg2) use ($var1, $var2) {
// body
};
参数列表以及变量列表可以分成多行，这样，包括第一个在内的每个参数或变量都必须单独成行，而列表的右括号与闭包的开始花括号必须放在同一行。
以下几个例子，包含了参数和变量列表被分成多行的多情况。
$longArgs_noVars=function (
$longArgument,
$longerArgument,
$muchLongerArgument
) {
// body
};
$noArgs_longVars=function () use (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// body
};
$longArgs_longVars=function (
$longArgument,
$longerArgument,
$muchLongerArgument
) use (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// body
};
$longArgs_shortVars=function (
$longArgument,
$longerArgument,
$muchLongerArgument
) use ($var1) {
// body
};
$shortArgs_longVars=function ($arg) use (
$longVar1,
$longerVar2,
$muchLongerVar3
) {
// body
};
注意，闭包被直接用作函数或方法调用的参数时，以上规则仍然适用。
$foo->bar(
$arg1,
function ($arg2) use ($var1) {
// body
},
$arg3
);
7. 总结
以上规范难免有疏忽，其中包括但不仅限于：
?全局变量和常量的定义
?函数的定义
?操作符和赋值
?行内对齐
?注释和文档描述块
?类名的前缀及后缀
?最佳实践
本规范之后的修订与扩展将弥补以上不足。
系统开发代码规范北京慧点科技开发有限公司 2005年9月
目录 一、Domino网络域及组织的命名................................................................ 错误！未定义书签。 二、Domino服务器的命名............................................................................ 错误！未定义书签。 三、系统验证字的命名................................................................................. 错误！未定义书签。 四、用户和群组的命名................................................................................. 错误！未定义书签。 五、模块数据库的命名................................................................................. 错误！未定义书签。 六、数据库各设计元素的命名..................................................................... 错误！未定义书签。 七、编码规范................................................................................................. 错误！未定义书签。 八、产品开发规范......................................................................................... 错误！未定义书签。 九、提交数据库备份命名规范..................................................................... 错误！未定义书签。
1.软件开发手册 1.1.围 本标准规定了基于公司信息系统构建平台进行业务应用系统开发的编程格式规，主要包括命名规、代码注释、性能、以及常用语句的书写要求和约束等。统一规的格式有利于项目的交付和后续维护。 1.2.引言 1.1.1.简介 所有的程序开发手册都包含了各种规则。一些习惯自由程序的人（例如 Java 程序员）可能对这些规则很不适应，但是在多个开发人员共同协作的情况下，这些规则是必需的。这不仅仅是为了开发效率，而且也为了测试和后期维护。 良好的编码习惯有助于标准化程序的结构和编码风格，使源代码对于自己和别人都易读和易懂。在开发周期中越早使用恰当的编码规定，将会最大程度的提高项目的生产率。良好的编码习惯除了代码格式，详细的注释外，还应该包括使用有助于提高程序效率的编码方式。 规的开发有助于提高源码的可读性，可维护性，对于提高项目的整体效率更是不可缺少的（尤其是团队开发）。 1.1. 2.目的 本文是一套面向Java programmer 和Java developer进行开发所应遵循的开发规。按照此规来开发Java程序可带来以下益处： ●代码的编写保持一致性， ●提高代码的可读性和可维护性， ●在团队开发一个项目的情况下，程序员之间可代码共享， ●易于代码的回顾。 1.3.源程序 1.3.1.源程序命名 Java源程序的名字应该是这种形式：ClassOrInterfaceName.java。ClassOrInterfaceName 应该是在Java源程序中定义的 class或者interface的名字（关于classes和interface的命
名规请参考3.2）。源程序的文件名后缀通常为.java。 1.3. 2.供发布的文件 如果文件编译后，需要用打包的形式发布，那么这个包的名字应该是有代表性的（例如应该是这个模块或者这个文件所在单元的名字）。通常包的扩展名有 *.jar(推荐使用)或者 *.zip、*.ear、*.war等。 1.3.3.源文件的组织 一个Java源文件应该包含如下的元素，并按照以下顺序书写： 1)版本信息和声明 2)包的声明 3)引用声明 4)类或者接口的声明 以上元素之间以至少一个空行来分隔。 1.3.3.1.版本信息和声明 每一个源程序应该以一个包含版本信息和声明的块为开始。 例如： /** * application name： sample1 * application describing： this class handels the request of the client * copyright： Copyright ? 2002 金质工程所有 * company： neusoft * time： 2002.02.25 * * author Brunce * version ver 3.1 */
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments）。我们不使用“文 档注释”这样的说法，而会直接说Javadoc。 其他“术语说明”，将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。
二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 2.2 文件编码：UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \", \'和\\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode 码（例如\u000a）表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者对应的Unicode 码（例如\u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
项目开发规范文档修订历史记录
1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册
3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。
目录 目录 (1) SAP开发规范 (3) 1说明 (3) 1.1内容说明 (3) 1.2规范目的 (3) 1.3使用说明 (3) 1.4使用对象 (3) 2一般规则 (3) 3代码管理 (4) 3.1程序标题 (4) 3.2子程序、模块标题 (5) 3.3编辑器设置 (5) 3.4代码格式 (7) 3.4.1使用规范化打印机 (7) 3.4.2查询SQL语句的写法 (7) 3.5变更记录管理 (7) 3.6代码注释 (8) 3.7子程序与函数模块 (9) 3.8其它注意事项 (9) 4数据库查询 (9) 4.1不要在L OOP循环中使用S ELECT语句 (9) 4.2取数的时候不能使用S ELECT......E NDSELECT语句循环操作 (9) 4.3尽量多使用内表 (9) 4.4S ELECT
5.2内表使用 (12) 5.2.1修改内表中的字段值 (12) 5.2.2把一个内表附加到另一个内表后面 (12) 5.2.3删除内表中重复行 (13) 5.2.4根据条件删除内表中的行 (13) 5.2.5内表是否为空的判断 (13) 5.2.6读取内表行 (13) 5.2.7通过LOOP AT it_tab ASSIGNING
Git源代码管理规范 一、分支管理 使用git进行源代码管理，一般将某个项目的所有分支分为以下几条主线： 1.Master 顾名思义，既然名字叫Master，那么该分支就是主分支的意思。master分支永远是production-ready的状态，即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了，不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后，就会合并到develop 分支去。 4.release branches 这个分支系列从develop分支出来，也就是预发分支。在预发状态下，我们往往会进行预发环境下的测试，如果出现缺陷，那么就在该release分支下进行修复，修复完毕测试通过后，即分别并入master分支后develop分支，随后master分支做正常发布。
5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复，当线上出现bug且特别紧急的时候，就可以从master拉出分支到这里进行修复，修复完成后分别并入master和develop 分支。 下面这张图将完整展示这一个流程
二、工作原理 Git的工作方式： 也就是说，每次提交版本变动的时候，git会保存一个快照(snapshot)。如果文件没有被更改，git也不会再次保存，而是提供一个到原来文件的链接。这样一来，git更像是一个小型的文件系统。此外，git的所有操作都可以是本地的，仅仅在将新版本的内容上传到服务器上时才需要连接网络。
项目团队开发规范
修订历史记录
目录 1引言 (6) 1.1 编写目的 (6) 1.2 预期读者 (6) 1.3 编写背景 (6) 2概述 (7) 2.1 目标 (7) 2.2 修改及完善 (7) 3详细规范 (7) 3.1 使用的工具 (7) 3.2 框架设计 (7) 3.3 包目录 (8) 3.4 编码规范 (10) 3.4.1 目的 (10) 3.4.2 依据 (10) 3.4.3 具体规范 (10) 3.4.3.1 编码风格 (10) 3.4.3.1.1 缩进 (10) 3.4.3.1.2 空格 (11) 3.4.3.1.3 对齐 (12) 3.4.3.1.4 空行 (12)
3.4.3.1.5 代码长度 (13) 3.4.3.1.6 行数 (13) 3.4.3.1.7 注释 (14) 3.4.3.2 代码效率 (17) 3.4.3.2.1 综述 (17) 3.4.3.2.2 具体实现 (17) 3.4.3.3 异常处理 (17) 3.4.3.3.1 处理CHECK 异常与UNCHECK异常 (17) 3.4.3.4 程序调试 (17) 3.4.4 日常交流 (18) 3.4.4.1 互相促进 (18)
1引言 1.1 编写目的 本文档作为项目团队开发规范的说明书，描述了项目开发过程中的使用的工具，框架，代码编写规范及注意问题，作为项目团队建设，开发及测试工作的依据。 1.2 预期读者 本文档的预期读者包括以下几类： ?项目组长 ?项目组全体成员 1.3 编写背景 根据公司现有的开发状况，决定组件稳定的项目开发团队，制定全体团队成员共识的开发规范，有助于提高项目开发的效率、项目团队整体水平的提升。
代码开发规范 1 前言 1.1 为什么需要开发规范 编码规范对于程序员而言尤为重要，有以下几个原因： * 一个软件的生命周期中，80%的花费在于维护 * 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护* 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码 * 如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品 1.2 开发规范的作用 * 减少维护花费 * 提高可读性 * 加快工作交接 * 减少名字增生 * 降低缺陷引入的机会
2 命名规范 2.1 常量命名规范 2.1.1 类型 常量命名规范 2.1.2 说明 常量用于保存需要常驻内存中并且经常使用变化不多的数据，定义常量的名称的时候需要遵循望文知意的原则； 2.1.3 规则 1.全部为大写字母； 2.中间以“_”连接； 3.望文知意原则； 2.1.4 备注 代码中涉及到直接使用某个字符串或者其他基本类型的值时，建议定义成常量，避免多处直接使用同样的值作为参数。 2.1.5 举例 ?如：定义一个常量表示最小屏幕宽度的常量，则可以定义一个int类型的常 量，该常量可以命名为：“MIN_SCREEN_WIDTH“； ?其他举例： ?例如：static final int MIN_SCREEN_WIDTH = 4；( √) ?例如：static final int min_screen_width = 4;（×） ?例如：static final int minScreenWidth = 4; （×） ?例如：static final int WIDTH = 4；（×）
4J 代码规范 1性能级别规范 1.1对潜在的业务级异常捕获处理打印日志，参照spring源代码 1.2controller或service层需要数据校验，确保系统安全，具体在哪一层校验需确认 1.3业务处理代码只能出现于service层，确保事务安全与mvc结构清晰，如jsp，controller都不能有 1.4严禁循环中连接数据库，确保一次请求不产生过多的数据库连接 1.5使用sql直接进行统计查询等业务复杂度较低的操作，确保java代码的可读性与java内存性能 1.6业务复杂的操作会涉及到多次数据库连接，包括多表查询，更新等，这种情况尽量避免，可以将部分业务合并在一个sql中，或者使用存储过程 1.7sql语句避免直接使用“*”，除非在外层语句 1.8不允许单一的count语句使用orderby，limit，count(*) 1.9查询时分组、排序、条件、结果字段影响效率时，应该跟组长或DBA讨论是否需要建立索引 1.10Java代码不允许sql参数字符拼接方式，必须使用预编译方式（除非参数绝对不发生变化），确保数据安全与查询效率 1.11表间关联字段类型一致，确保索引不会失效 1.12mysql中没有函数索引，所以查询时尽量不要有索引列的函数，如substr(create_date, 1, 6) = substr('20110728', 1, 6) 实质是等于某月改写为 ——————————————————————————————————————————————————————————————— - 1 -
create _date >=to_char(last_day(add_months(to_date('20110728','yyyymmdd'),-1)) + 1,'yyyymmdd')and create _date <= 该月最后一天 1.13编写sql时避免大表的全表扫描，尽量走索引，正确使用left join,right join,join对数据和效率影响 2代码基本规范 2.1数据库所有字段都为大写，单词之间用_分隔 2.2在所有JSP、JAVA代码中，如果是一个数据库字段对应的变量，则名称和数据库字段名称相同 2.3在JAVA、JSP中，除了与数据库字段对应的变量以外的所有变量，都以小写字母开头驼峰式命名，变量中各单词之间不要空格，不要有其它字母， 例如helloWorld 是正确的HelloWorld 、hello_world 这些都是错误的。 2.4代码提交到SVN时，在提交界面中，请写清修改的原因、事项 2.5在处理日期型的数据字段时，注意不要随意书写，要兼容ORACLE的写法 2.6在使用GROUP BY语句的时候，要注册兼容ORACLE的写法 2.7凡是牵扯到数据持久化的代码都要封装到dao层，切不可以在bean或者其他的层中写操作数据库的代码。 3代码书写原则 3.1JSP页面中，尽可能不写或者少写JAVA代码 3.2所有JS代码，都写在JSP页面的上方 3.3所有JSP代码、JS代码，都要写上完善的注释，因为这部分代码，会被经常改动。 4文件命名规范 ——————————————————————————————————————————————————————————————— - 2 -
1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)
1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。
1.程序版式 1.1.对齐 1.1.1.程序块要采用缩进风格编写，缩进的空格数为4个。使用VC提供的Tab 键对齐。 1.1. 2.“{”和“}”应独占一行并且位于同一列，同时引用他们的语句对齐1.1. 3.{}之内的代码块在“{”右边数格外左对齐 例： 正确错误
1.2.空行 1.2.1.每个声明之后，每个函数定义之后要加空行 1.2.2.在一个函数体内，逻辑上密切相关的语句之间不加空行，其它地方应加空 行分隔 1.2.3.变量声明和代码之间加空行 1.2.4.函数返回语句用空行 例：
1.3.代码行 1.3.1.一行代码只做一件事情，如只定义一个变量，或只写一条语句。 1.3. 2.if、for、do、while、case、switch、default等语句自占一行，且if、for、 do、while等语句的执行语句部分无论多少都要加括号{} 例： 示例：风格良好的代码行示例：风格不良的代码行 1.4.空格 1.4.1.关键字之后要留空格：const, virtual, inline, if, while, for 1.4. 2.函数名之后不要留空格 1.4.3.“（”向后紧跟“，”，“、”，“.”，“；”，“）”向前紧跟 1.4.4.“，”后要留空格，“”；之后如果不是一行的结束，后面要留空格 1.4.5.赋值操作符，比较，算术，逻辑，第二元操作符前后加空格 1.4.6.一元操作符！、~、++、--、—等前后不加空格 1.4.7.像[]、“.”、—＞等前后不加空格
例： 1.5.长行拆分 1.5.1.代码行最长度宜控制在70到80个字符以内，代码行不宜过长 1.5. 2.长表达式拆分，应将操作符放在新行之首，拆分出新行要适当缩进，使排 版整齐 例：
XXXXXXXX 代码版本管理规范
历史版本
目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)
1引言 1.1目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
2现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库 中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试
HTML/CSS代码开发规范文档
目录 1、前言 (4) 2、HTML编码规范 (4) 2-1HTML标记的关闭规范 (4) 2-2HTML文件头基本标记 (4) 2-2HTML正文代码标记元素 (5) 2-3HTML标记的缩进规范 (6) 3、HTML文件引入CSS样式代码和Javascript代码规范 (6) 3-1引入css样式代码规范 (6) 3-2引入Javascript代码规范 (7) 4、HTML注释标签 (8) 5、CSS编码规范 (8) 5-1 CSS编码要求 (8) 5-2 CSS样式表规范 (8) 5-3 CSS命名规范 (9) 5-4样式文件命名 (10) 5-5样式文件布局 (11) 6、CSS常规书写规范及方法 (11) 6-1文件调用方法: (11) 6-2 CSS结构化书写 (11) 6.2.1派生选择器： (11) 6.2.2辅助图片用背影图处理： (12) 6.2.3结构与样式分离： (12) 6.2.4文档的结构化书写 (12) 6-3 HACK CSS书写规范 (13) 6.3.1 IE6、IE7、Firefox之间的兼容写法 (13) 6.3.2屏蔽IE浏览器 (14) 6.3.3清除浮动 (14) 6.3.4鼠标手势 (15) 7、CSS性代码缩写 (15) 7.1不同类有相同属性及属性值的缩写 (15) 7.2同一属性的缩写 (16) 7.3内外侧边框的缩写 (16) 7.4颜色值的缩写 (18) 8、CSS注释书规范 (18) 8.1行间注释 (18) 8.2整段注释 (18)
1、前言 本编程规范适用于需要编写HTML/CSS代码的网页程序开发人员。本规范并不是一个一成不变的必须严格遵守的条文，特殊情况下要灵活运用，做一定的变通。 2、HTML编码规范 HTML是一种标记语言, HTML没有任何真正的编程语言中的循环或是流程控制语句。然而，HTML代码的格式和风格是非常重要的，因为要经常对HTML代码进行维护和修改，因此HTML代码必须有很清晰的逻辑结构和布局,增强可读性，而使其易懂和易于维护。HTML代码本身是不区分大小写的，但是为了更好的统一代码布局，项目中HTML文件标记都以小写为主。 2-1HTML标记的关闭规范 HTML文档的正文都应在
标记中间，而标记则应包含在和标记之间。如： 正文 不同类的标记不能交叉编码： eg: 内容 正确编码应为：内容 开始和关闭标记放在一行的标记有: eg: 和 和 和 各种标题标记，如代码编写规范说明书（c#.net与https://www.doczj.com/doc/2111738177.html,）目录 1 目的 2 范围 3 注释规范 3.1 概述 3.2 自建代码文件注释 3.3 模块（类）注释 3.4 类属性注释 3.5 方法注释 3.6 代码间注释 4 命名总体规则 5 命名规范 5.1 变量（Variable）命名 5.2 常量命名 5.3 类（Class）命名 5.4 接口（Interface）命名 5.5 方法（Method）命名 5.6 名称空间Namespace）命名 6 编码规则 6.1 错误检查规则 6.2 大括号规则 6.3 缩进规则 6.4 小括号规则 6.5 If Then Else规则 6.6 比较规则 6.7 Case规则 6.8 对齐规则 6.9 单语句规则 6.10 单一功能规则 6.11 简单功能规则 6.12 明确条件规则 6.13 选用FALSE规则 6.14 独立赋值规则 6.15 定义常量规则 6.16 模块化规则 6.17 交流规则 7 编程准则 7.1 变量使用 7.2 数据库操作 7.3 对象使用 7.4 模块设计原则 7.5 结构化要求 7.6 函数返回值原则 8 代码包规范 8.1 代码包的版本号
8.2 代码包的标识 9 代码的控制 9.1 代码库/目录的建立 9.2 代码归档 10 输入控制校验规则 10.1 登陆控制 10.2 数据录入控制 附件1：数据类型缩写表 附件2：服务器控件名缩写表 1 目的 一.为了统一公司软件开发设计过程的编程规范 二.使网站开发人员能很方便的理解每个目录,变量，控件，类，方法的意义 三.为了保证编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。 四.编码规范和约定必须能明显改善代码可读性，并有助于代码管理、分类范围适用于企业所有基于.NET平台的软件开发工作 2 范围 本规范适用于开发组全体人员，作用于软件项目开发的代码编写阶段和后期维护阶段。 3 注释规范 3.1 概述 a) 注释要求英文及英文的标点符号。 b) 注释中，应标明对象的完整的名称及其用途，但应避免对代码过于详细的描述。 c) 每行注释的最大长度为100个字符。 d) 将注释与注释分隔符用一个空格分开。 e) 不允许给注释加外框。 f) 编码的同时书写注释。 g) 重要变量必须有注释。 h) 变量注释和变量在同一行，所有注释必须对齐，与变量分开至少四个“空格”键。 如：int m_iLevel,m_iCount; // m_iLevel ....tree level // m_iCount ....count of tree items string m_strSql; //SQL i) 典型算法必须有注释。 j) 在循环和逻辑分支地方的上行必须就近书写注释。 k) 程序段或语句的注释在程序段或语句的上一行 l) 在代码交付之前，必须删掉临时的或无关的注释。 m) 为便于阅读代码，每行代码的长度应少于100个字符。 3.2 自建代码文件注释 对于自己创建的代码文件（如函数、脚本），在文件开头，一般编写如下注释： /****************************************************** FileName: Copyright (c) 2004-xxxx *********公司技术开发部 Writer: create Date: Rewriter:
安全代码编写规范 一、编写目的 为加强我司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。 二、 三、 四、使用范围 本规范适用于百度有限公司的开发类软件项目。 五、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商
定第三方接入的身份认证方式和手段。 六、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括< > " ' % ( ) & + \ \' \"等。 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对