PHP代码文档规范及phpDoc指南-共享版
PHP文档规范及phpDoc指南
目录
1概述 (3)
2PHPDoc/ phpDocumentor (3)
2.1什么是PHPDoc/phpDocumentor (3)
2.2phpDocumentor1和phpDocumentor2 (5)
2.3phpDocumentor安装 (5)
2.3.1pear安装 (5)
2.3.2phpDocumentor安装 (6)
3使用phpDocumentor生成文档 (6)
3.1phpDocumentor使用说明 (6)
3.2生成指定目录下的文档 (6)
3.3生成指定文件的文档 (6)
3.4指定文档标题 (7)
4PHP注释规范 (7)
4.1需要特别注意的地方 (7)
4.2文件、类注释 (8)
4.3方法注释 (8)
4.4常用tag标签 (9)
4.4.1常用tag列表 (9)
4.4.2@param变量类型列表 (9)
4.5常用的嵌入式{@tag }用法 (10)
4.5.1{@link}用法 (10)
4.5.2{@source}用法 (10)
4.5.3其他inline tag (11)
4.6用法 (11)
5参考资料 (12)
1概述
对于一个开发人员，文档总是最感到头疼的事情之一。而且，很可能你对待文档会采取截然不同的2种态度：
●当你使用别人的代码库的时候，最希望得到的是它的技术文档，尤其是当时间很紧，而你又不得不硬
着头皮去读那些生涩的代码的时候。
●当写你自己的程序的时候，最不希望做的事情却是给它编写专门的技术文档，你会以种种理由给自己
开脱：我的代码已经足够清晰了，完全不用再为它重新编写文档了……
为了解决这个问题，文档工具由此产生。按照规范格式编写代码注释，当代码写完了，技术文档也就完成了。良好的代码注释不仅能够帮助开发人员在编写代码时缕清思路，尽可能避免逻辑bug，而且规范的代码注释还能够使用文档工具直接生成API手册。
2PHPDoc/ phpDocumentor
2.1什么是PHPDoc/phpDocumentor
PHPDoc（现在项目名改为了phpDocumentor）是PEAR下面的一个非常优秀的模块，它的目标是实现类似javadoc的功能，可以为你的代码快速生成具有相互参照，索引等功能的API文档。
目前PHPDoc有3个主要的版本：
●PHPDoc：此版本最高到 1.0beta，已经停止维护，升级为phpDocumentor，PHPDoc的官网是
http://www.phpdoc.de/，有兴趣的话可以看看。此版本生成的文档格式如下图：
●phpDocumentor1：此版本最高到1.4.4，已经升级到phpDocumentor2，目前网上大部分的PHP开源项目都
是由此版本工具生成的API手册。官网：https://www.wendangku.net/doc/006944800.html,/，此版本生成的文档格式如下图：
●phpDocumentor2：此版本还在升级维护中，目前最高版本是2.0.0alpha1。官网：https://www.wendangku.net/doc/006944800.html,/，
此版本生成的文档格式如下图：
2.2phpDocumentor1和phpDocumentor2
因为最初的版本PHPDoc早已停止维护和升级，本文不再介绍和使用。phpDocumentor从1.4.4直接升到了phpDocumentor2，2比较于1做了如下改变：
●High performance：更高的性能。优化后的phpDocumentor生成同一个项目的文档，比前一版本最高节省
90秒。
●Template System：提供了非常灵活的模板系统，用户可以订制自己的API手册样式。而且也修正了1.4.4
非常讨厌的默认iso-8859-1编码，改成了默认utf-8。
●Reports & Charts：可以生成开发人员可能感兴趣的图标和报告，如类的继承关系、接口实现拓扑图，TODO
就列表等。
●Plugins：增加了以AoP模式实现的的插件功能，开发人员可以开发或重写自己的tag解释方法。
在安装和使用上，phpDocumentor1和phpDocumentor2基本一样，所以下文就统一以phpDocumentor说明。（因为phpDocumentor2的默认responsive模板生成的文档实在不太好看和不习惯，而且phpDocumentor2的新特性大多都用不上，所以笔者现在用的是能够生成https://www.wendangku.net/doc/006944800.html,上PHP手册样式的phpDocumentor1.4.4）
2.3phpDocumentor安装
2.3.1pear安装
因为phpDocumentor是PEAR的一个模块，虽然phpDocumentor也支持单独下载使用，但最后以PEAR模块安装。所以如果PHP没有安装PEAR，需要先安装PEAR：
Mac OS X：
2.3.2phpDocumentor安装
●phpDocumentor1.4.4
安装要求：PHP version 4.1.0或以上
说明：phpDocumentor1.4.4比较讨厌的地方是文档的tpl模板默认编码是iso-8859-1，而不是常用的utf-8，如果不修改的话可能会产生中文乱码的问题。修改默认编码方法如下：
找到PEAR的安装目录，以笔者的电脑为例，PEAR的安装目录是：/opt/local/lib/php/pear
●phpDocumentor2
安装要求：PHP 5.2.6或以上，最好安装有XSL和Graphviz扩展。如果需要生成PDF格式的文档，还需要安装wkhtmltopdf扩展。
3使用phpDocumentor生成文档
3.1phpDocumentor使用说明
使用phpdoc –h命令可以产看帮助手册，本文不再详述。
3.2生成指定目录下的文档
3.3生成指定文件的文档
3.4指定文档标题
4PHP注释规范
4.1需要特别注意的地方
●需要生成文档的注释必须是以“/**”开头，以“*/”结尾。主流的IDE开发工具（如Eclipse，Zend）会
用不同的颜色来区分下面的几种注释。
●
●
一般以“/*”开头，而public方法以“/**”开头。
4.2文件、类注释
4.3方法注释
4.4常用tag标签
4.4.1常用tag列表
特别说明；
●@version：如果代码版本控制工具使用的是CVS，可以设置成“@version$Id: Exp $”，CVS在提交代码时
会自动填充文件的版本信息
●@see：当某些注释说明已经写过不想再重复写，或有关联的方法或类需要参见，此时用到@see
4.4.2@param变量类型列表
@param 标签需要指定参数类型，可以使用的类型如下：
●string 该参数是一个字符型变量。
●array 该参数是一个数组。
●int该参数是一个数值型，同integer
●integer 该参数是一个数值型。
●integer (octal) 该参数是一个数值型，并且是按照八进制方式存放。
●integer (hexadecimal) 该参数是一个数值型，并且是按照十六进制方式存放。
●boolean 该参数是一个布尔型。
●mixed 该参数的类型是可变的，可以上面几种类型的组合。不过，在随后的说明中一般要说明可以接受的
变量的类型。
●void 无返回值，只用于@return标签，如@return void
以上类型同样适用于@property和@return
4.5常用的嵌入式{@tag }用法
嵌入式{@tag }（即inline tag）是在写注释文字段时，需要在文字段中加入链接或锚点，此时用到嵌入式tag。
4.5.1{@link}用法
在写注释文字段时需要加一些URL链接或是锚点，在生成的文档中用户可以通过鼠标点击进入这个链接或锚点，或是有关联的方法或类需要参见，此时用到{@link}。
格式如下：
{@link URL [description]}
{@link element [description]}
举例：
4.5.2{@source}用法
当需要在文档中显示具体的实现代码时，可以使用此标签。格式如下：
●显示该方法或类的所有代码：{@source}
●显示从指定行开始到方法或类的结尾代码：{@source startline}
●显示从指定行开始，到指定的行数结束的代码：{@source startline number_of_lines}
* {@source }
* displays without a break in the flow
*/
function element($pages)
{
if (empty($pages))
{
die("ERROR: nothing parsed");
}
}
相当于===》
/**
* Text with an inline source tag:
*
*
* function element($pages)
* {
* if (empty($pages))
* {
* die("ERROR: nothing parsed");
* }
* }
*
* displays without a break in the flow
*/
当然，如果不用此标签也可以直接使用标记，具体说明见下文。
4.5.3其他inline tag
其他的不太常用，具体参见官方文档：https://www.wendangku.net/doc/006944800.html,/docs/latest/index.html
4.6用法
标签的主要作用是为了显示代码段示例。当然，如果有大段的注释文本，而又懒得去加
等HTML标签进行换行美化，也可以使用此标签。
5参考资料
1、https://www.wendangku.net/doc/006944800.html,/developerworks/cn/linux/sdk/php/pear3/index.html
2、https://www.wendangku.net/doc/006944800.html,/
源代码安全管理制度V
技术部源代码控制管理制度V1.0 一、总则 1、目的: 为保障公司源代码安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、使用范围: 本办法适用于所有涉及接触源代码的各部门各岗位，所涉及部门都必须严格执行本管理办法。 3、责权: 源代码直接控制管理部门为技术部。本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个平台系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 二、管理内容及要求(根据部门工作情况撰写) 1、源代码完整性保障 所有系统的源代码及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定SVN库中。
我们研发的平台系统运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的SVN库中。 功能开始编写或者调整代码之前，其相应的设计文档必须签入SVN库（由测试组文档管理员负责检查）。 系统编码或代码调整优化结束后，提交技术测试组功能测试之前，相应的源代码必须提交到SVN库。 测试组对功能进行测试时必须从源代码服务器上的SVN库中获取代码，包括必须的第三方软件、控件和其它支撑库等文件，然后进行测试。 所有提交到SVN上的代码必须保证编译通过,而且提交的时候不会影响主干其它程序的正常运行. 2、源代码的授权访问 源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。（由SVN管理员进行管理和设置） 在SVN库中设置用户，为不同用户分配不同的、适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可创建权、可编辑权、可删除权、可销毁权。每个用户切实保证自己的用户身份和口令不泄露,用户要经常更换自己在SVN库中账号的口令。同时，工作任务变化或岗位调整后SVN管理员要实时回收用户的相关权限。要获取不属于自己范围内的文件，例如：代码、数据库，需求文档等，需经项目经理和技术部经理审批同意后由SVN管理员授权。
PHP代码文档规范及phpDoc指南-共享版
PHP文档规范及phpDoc指南
目录 1概述 (3) 2PHPDoc/ phpDocumentor (3) 2.1什么是PHPDoc/phpDocumentor (3) 2.2phpDocumentor1和phpDocumentor2 (5) 2.3phpDocumentor安装 (5) 2.3.1pear安装 (5) 2.3.2phpDocumentor安装 (6) 3使用phpDocumentor生成文档 (6) 3.1phpDocumentor使用说明 (6) 3.2生成指定目录下的文档 (6) 3.3生成指定文件的文档 (6) 3.4指定文档标题 (7) 4PHP注释规范 (7) 4.1需要特别注意的地方 (7) 4.2文件、类注释 (8) 4.3方法注释 (8) 4.4常用tag标签 (9) 4.4.1常用tag列表 (9) 4.4.2@param变量类型列表 (9) 4.5常用的嵌入式{@tag }用法 (10) 4.5.1{@link}用法 (10) 4.5.2{@source}用法 (10) 4.5.3其他inline tag (11) 4.6用法 (11) 5参考资料 (12)
1概述 对于一个开发人员，文档总是最感到头疼的事情之一。而且，很可能你对待文档会采取截然不同的2种态度： ●当你使用别人的代码库的时候，最希望得到的是它的技术文档，尤其是当时间很紧，而你又不得不硬 着头皮去读那些生涩的代码的时候。 ●当写你自己的程序的时候，最不希望做的事情却是给它编写专门的技术文档，你会以种种理由给自己 开脱：我的代码已经足够清晰了，完全不用再为它重新编写文档了…… 为了解决这个问题，文档工具由此产生。按照规范格式编写代码注释，当代码写完了，技术文档也就完成了。良好的代码注释不仅能够帮助开发人员在编写代码时缕清思路，尽可能避免逻辑bug，而且规范的代码注释还能够使用文档工具直接生成API手册。 2PHPDoc/ phpDocumentor 2.1什么是PHPDoc/phpDocumentor PHPDoc（现在项目名改为了phpDocumentor）是PEAR下面的一个非常优秀的模块，它的目标是实现类似javadoc的功能，可以为你的代码快速生成具有相互参照，索引等功能的API文档。
Git源代码管理规范样本
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的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。
PHP开发规范标准
目录 1、编写目的 (4) 2、整体要求 (5) 3、安全规范 (6) 3.1、包含文件 (6) 3.1.1、命名规则 (6) 3.1.2、存放规则 (6) 3.2、安全规则 (7) 3.3、一些针对PHP的规则 (8) 3.4、其它处理规则 (8) 3.4.1、输入参数处理 (8) 3.4.2、操作大HTML文本 (8) 4、编码规范 (9) 4.1、命名规范 (9) 4.1.1、变量命名 (9) 4.1.2、类命名 (10) 4.1.3、方法或函数 (10) 4.1.4、缩写词 (11) 4.1.5、数据库表名 (11) 4.1.6、数据库字段 (11) 4.2、书写规则 (11) 4.2.1、代码缩进 (12) 4.2.2、大括号{}书写规则 (12) 4.2.3、小括号()和函数、关键词等 (13)
4.2.4、=符号书写 (13) 4.2.5、if else swith for while等书写 (13) 4.2.6、类的构造函数 (13) 4.2.7、语句断行 (14) 4.2.8、数字 (14) 4.2.9、判断 (15) 4.2.10、避免嵌入赋值 (15) 4.2.11、错误返回检测规则 (16) 4.3、程序注释 (16) 4.3.1、程序头注释块 (16) 4.3.2、类的注释 (17) 4.3.3、函数和方法的注释 (18) 4.3.4、变量或者语句注释 (18) 4.4、其它规范 (19) 4.4.1、PHP代码标记 (19) 4.4.2、程序文件名、目录名 (19) 4.4.3、PHP项目通常的文件目录结构 (19) 4.4.4、PHP和HTML代码的分离问题 (20) 4.4.5、PHP项目开发中的程序逻辑结构 (20) 5、特定环境下PHP编码特殊规范 (21) 5.1、变量定义 (21) 5.2、引用的使用 (21) 5.3、变量的输入输出 (22)
php项目开发规范
竭诚为您提供优质文档/双击可除php项目开发规范 篇一：整理了一份比较全面的php开发编码规范. 整理了一份比较全面的php开发编码规范. 目录 1编写目的 2整体要求 3安全规范 3.1包含文件 3.1.1命名规则 3.1.2存放规则 3.2安全规则 3.3一些针对php的规则 3.4其它处理规则 3.4.1对输入参数值进行转义处理 3.4.2操作大html文本 4编码规范 4.1命名规范 4.1.1变量命名
4.1.2类 4.1.3方法或函数 4.1.4缩写词 4.1.5数据库表名 4.1.6数据库字段 4.2书写规则 4.2.1代码缩进 4.2.2大括号{}书写规则 4.2.3小括号()和函数、关键词等 4.2.4＝符号书写 4.2.5ifelseswithforwhile等书写 4.2.6类的构造函数 4.2.7语句断行,每行控制在80个字符以内4.2.8不要不可思议的数字 4.2.9true/false和0/1判断 4.2.10避免嵌入式赋值 4.2.11错误返回检测规则 4.3程序注释 4.3.1程序头注释块 4.3.2类的注释 4.3.3函数和方法的注释 4.3.4变量或者语句注释
4.4其他规范（建议） 4.4.1php代码标记 4.4.2程序文件名、目录名 4.4.3php项目通常的文件目录结构 4.4.4php和html代码的分离问题 4.4.5php项目开发中的程序逻辑结构 5特定环境下php编码特殊规范 5.1变量定义 5.2引用的使用 5.3变量的输入输出 1编写目的 为了更好的提高技术部的工作效率，保证开发的有效性和合理性，并可最大程度的提高程序代码的可读性和可重复利用性，指定此规范。开发团队根据自己的实际情况，可以对本规范进行补充或裁减。 2整体要求 技术部php开发规范将参照peaR的规范，基本采用peaR 指定的规范，在其基础上增加、修改或删除部分适合具体开发环境的规范。本规范只针对php开发过程中编码的规范，对于php开发项目中文件、目录、数据库等方面的规范，将不重点涉及。 本规范包含了php开发时程序编码中命名规范、代码缩
PHP代码编写规范
QC 质量管理体系文件 代码编写规范 受控状态：■受控□非受控 发布日期：2006年02月20日 实施日期：2006年02月24日
1. 引言 1.1. 目的 制定本规范是为了能达到以下目的： ●提高程序员工作效率和代码的利用性 ●程序员可以了解任何代码，弄清程序的状况 ●新人可以很快的适应环境 ●防止新接触php的人出于节省时间的需要，自创一套风格并养成终生的习惯 ●防止新接触php的人一次次的犯同样的错误 ●在一致的环境下，人们可以减少犯错的机会 1.2. 适用范围 适用于本公司的所有开发人员，包括数据库、网页及应用程序开发人员，及有关的程序测试人员。 1.3. 引用标准 GB/T 8566-1995 信息技术软件生存期过程 GB/T 8567-1988 计算机软件产品开发文件编写指南 1.4. 术语 GB/T 11457-1995中所使用的术语适用于本规范。
2. 代码编写规则 2.1. 注释 （1）编写代码期间注释要求占程序总量15%以上。 （2）每个模块顶部必须说明模块名称、功能描述、作者等。 （3）每个过程、函数、方法等开头部分必须说明功能、参数、返回值、原数据和目标数据数据结构等等。 （4）变量定义的行末应当对变量给出注释。 （5）程序在实现关键算法的地方应当给出注释 2.2. 变量、函数、过程、控件等命名规则 （1）变量命名采用[作用范围][数据类型][自定义名称]规则定义，要求看到变量名就能直观的看出其范围和数据类型。 （2）函数、过程、方法、事件等命名应尽量做到观其名知其义。 （3）控件的命名采用[控件类型][自定义名]规则定义,要求通过名字能直观看出控件类型。 （4）自定义命名空间规则，要求能顾名思义 2.3. 源代码规则 风格约定：采用缩进的格式保存程序的层次结构。要求能直观的看出循环、判断等层次结构。
源代码管理制度
源代码管理制度 1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 1.3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。在SVN库中设置用户，并为不同用户分配不同的权限，适合工作的最小访问权限。
要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 1.4代码版本管理 1、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。终端型号：终端型号是硬件标识号，也唯一的标识了我们的项目。版本号：由“＜主版本号＞.＜次版本号＞.＜修订号＞”三段组成，中间是点号分开。版本号的目的主要是管理终端软件的对外发布，终端软件的bug的记录和统计，主要是针对于版本号的，测试部、项目部、客户等会记录某个版本号的终端软件存在哪些bug，bug会在哪个版本号中得到修正。终端软件一个新的版本号出来后，我们会统计新的版本号解决了上一个版本号中的哪些bug，以及增加了哪些新功能，等等。 内部修订号：也就是“应用程序的源代码的svn修订号”，主要是由软件部和测试部内部来使用，内部修订号唯一标识我们的终端软件，即：通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码，目的是为了软件排错使用。 另外，终端软件在发布时，还会给出发布日期，以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理 终端软件主要是以版本号为基准，对外发布，目前采用不定时发布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量决定。 由于目前项目时间紧，终端软件无法得到完整的测试就要发布，在发布之后，有一些需要紧急需要修复的bug，软件部需要紧急修复后就要发布更新包，以便用户能够使用，所以，在一个版本号发布后，需要进行多次修订，对于这些修订的版本，其版本号保持不变，内部修订发生变化。 3、软件bug记录、管理和统计 软件bug的记录、管理和统计主要以版本号为基准，但为了软件开发人员能够找到bug
源代码管理规范
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库中要求区别对待不同用户的可访问权、可读权、可写权。
养成良好的代码规范
20期BBS小组编码规范 2.适用范围 (1) 3.标准化的重要性和好处 (1) 4.PHP编码规范与原则 (2) 4.1.代码标记 (2) 4.2.注释 (2) 4.3.书写规则 (3) 4.3.1.缩进 (3) 4.3.2.大括号{}、if和switch (3) 4.3.3.运算符、小括号、空格、关键词和函数 (4) 4.3.4.函数定义 (4) 4.3.5.引号 (5) 4.4.命名原则 ..................................................................................................................... 错误！未定义书签。 4.4.1.变量、对象、函数名 (6) 4.4.2.常量 (6) 4.5.变量的初始化与逻辑检查 (6) 4.6.安全性 ......................................................................................................................... 错误！未定义书签。 4.7.兼容性 ......................................................................................................................... 错误！未定义书签。 4.8.代码重用 (7) 4.9.其他细节问题 (7) 4.9.1.包含调用 (7) 4.9.2.错误报告级别8 1.适用范围 如无特殊说明，以下规则要求完全适用于Discuz!项目，同时也可大部分适用于COMSENZ 旗下其他PHP项目。 2.标准化的重要性和好处 当一个软件项目尝试着遵守公共一致的标准时，可以使参与项目的开发人员更容易了解 项目中的代码、弄清程序的状况。使新的参与者可以很快的适应环境，防止部分参与者出于 节省时间的需要，自创一套风格并养成终生的习惯，导致其它人在阅读时浪费过多的时间和 精力。而且在一致的环境下，也可以减少编码出错的机会。缺陷是由于每个人的标准不同，
代码版本管理规范_v1.1
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，研发修改，再提交测试，然后预发布测试
腾讯PHP开发规范v1.0
海豹平台开发规范v1.0 腾讯科技（深圳）有限公司 *版本信息&保密等级 版本更改日期更改要点说明编制审核批准
V1.0 2014/12/24 新建wilsonwsong V1.1 2014/12/26 修订rusherding 文档保密等级：□机密■内部□公开
目录 海豹平台开发规范V1.0 (1) 1 引言 (5) 1.1定义及缩略语 (5) 1.2参考文档 (5) 1.3目的 (5) 1.4适用范围 (5) 1.5标准化作用 (5) 2 目录结构规范 (6) 2.1框架路径 (6) 2.2应用目录结构 (6) 2.2.1 配置config (7) 2.2.2 控制器controllers (7) 2.2.3 模型models (7) 2.2.4 视图views (8) 2.2.5 国际化messages (8) 2.2.6 组件components (8) 2.2.7 命令commands (8) 2.2.8 临时目录runtime (8) 2.3路径别名 (8) 2.3.1 类型导入 (8) 3 PHP编码规范 (9) 3.1标签 (9) 3.2编码 (9) 3.3注释 (9) 3.3.1 文件注释 (9) 3.3.2 类注释 (10) 3.3.3 方法注释 (10) 3.3.4 属性注释 (11) 3.3.5 其它 (11) 3.4命名规则 (11) 3.4.1 文件 (11) 3.4.2 类 (11) 3.4.3 函数/方法 (12)
3.4.4 变量名 (12) 3.4.5 常量名 (12) 3.5书写规则 (13) 3.5.1 文件 (13) 3.5.2 行 (13) 3.5.3 缩进 (13) 3.5.4 控制结构 (13) 3.5.5 运算符 (16) 3.5.6 引号 (16) 3.5.7 关键词 (17) 3.5.8 函数 (17) 3.5.9 类 (17) 3.5.10 属性 (18) 3.5.11 方法 (18) 4 数据库命名规范 (20) 4.1命名规范 (20) 4.2实体命名 (20) 4.2.1 前缀命名 (20) 4.2.2 后缀命名 (21) 4.3字段命名 (21) 4.3.1 后缀命名 (22) 4.4字段类型 (22) 4.4.1 数值类型 (22) 4.4.2 字符类型 (23) 4.4.3 时间类型 (23) 4.4.4 ENUM&SET (23) 4.4.5 LOB 类型 (23) 4.5表结构设计 (24) 4.5.1 适度冗余 (24) 4.5.2 尽量使用NOT NULL (24) 4.5.3 索引 (24) 5 附件 (24) 5.1附录一：MYSQL保留字 (24)
源代码管理规范
1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)
1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
源代码管理规范
源代码管理规范 标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。 系统初验........................................................................................... 错误!未定义书签。 试运行............................................................................................... 错误!未定义书签。 系统终验........................................................................................... 错误!未定义书签。 系统验收标准................................................................................... 错误!未定义书签。 文档评审通过标准........................................................................... 错误!未定义书签。 确认测试通过标准........................................................................... 错误!未定义书签。 系统试运行通过标准....................................................................... 错误!未定义书签。
代码风格规范
代码风格规范 本篇规范是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. 例子 以下例子程序简单地展示了以上大部分规范： $b) { $foo->bar($arg1); } else { BazClass::bar($arg2, $arg3); } } finalpublicstaticfunction bar() { // method body }
Php编程规范
PHP编程规范 （试行）
前言 为规范PHP开发的编码风格，提高开发效率和降低开发人员的时间成本，建立统一的PHP开发标准体系，依据国际、国内相关标准、法规，参照国际、国内通行的职业技能标准制定本规范。 本规范由大连市经济和信息化委员会提出并归口。 本规范项目召集单位： 本规范项目专家组： 本规范主要起草单位： 本规范起草人： 本规范于二○一○年十一月四日首次发布。
目录 1. 适用范围 (5) 2. 定义和术语 (5) 2.1 PHP语言 (5) 2.2 程序代码 (5) 3. 代码编写格式 (5) 3.1 代码标记 (5) 3.2 缩进 (5) 3.3 长度 (5) 3.4 行宽 (6) 3.5 间隔 (6) 3.6 对齐 (6) 3.7 括号 (6) 4. 注释 (7) 4.1 预注释 (7) 4.2 类、接口注释 (8) 4.3 函数方法注释 (8) 4.5 其它注释 (9) 5. 命名 (9) 5.1 文件 (9) 5.2 变量 (9) 5.3 常量 (10) 5.4 类、接口 (10) 5.5 方法、函数 (10) 6. 声明 (10)
6.1 类、接口 (10) 6.2 方法 (10) 6.3 变量 (11) 6.4 常量 (11) 6.5 其他 (11) 7. 表达式与语句 (12) 7.1 控制语句 (12) 7.2 循环语句 (12) 8. 错误与异常 (13) 8.1 已检查异常与运行时异常 (13) 8.2 异常错误提示设置 (13) 9. 测试与 BUG 跟踪 (13) 9.1 测试基本原则 (13) 9.2 BUG 跟踪和缺陷处理 (13) 10. 性能与安全 (13) 10.1 输入与输出 (13) 10.2 针对 PHP.INI 的规则 (14) 10.3 SQL 语句处理规则 (14) 11. 其它 (14) 12. 附录 (14) 12.1 注释模板 (14)
PHP代码规范
PHP规范草案 Ver.0.0.1 1.变量命名与类的命名 (1) 类型 + 变量名： $inum 基于PHP语言弱类型的特点，以匈牙利命名法为参考，但国人不习惯大写字母，所以纯小写，为基本规范。 字符+命名的方式，比如 $susername 一个类型字符 一个类型 s代表字符串，i代表整型，a代表数组，o代表对象, r代表资源, b布尔型，例子： 01.$inum = 55; 02.$itotal = 110; 03.$susername = 'root'; 04.$spassword = '123456'; 05.$rlink =mysql_connect('localhost', 'root', '123456'); 06.$odb = new dbstuff(); 07.$anumber = array(1, 2, 3, 4, 5); 特殊常用的少数变量，可以不用书写前缀，比如 $uid, $sid, $sql, $row, $db 程序员的类型 的类型这种书写方式缺点：略需一点适应成本，但习惯后对程序员 这种书写方式缺点：略需一点适应成本，但习惯后对 开发和代码阅读调试意义重大。 和代码阅读调试意义重大。 思维有帮助，对团队开发 思维有帮助，对团队 设计字段类型及长度字符串类型一般没有 数据库设计字段类型及长度字符串类型一般没有 (2) 常用的命名及 常用的命名及数据库 默认值，而非主键的数值类型，非空，默认值为0。 username 用户名, char(16) password 密码, char(32) email 邮件, char(50) 时间，，int(10) dateline时间 register 注册 login 登陆 adminid 管理员id，某某id的命名，采用名字+id的方式， 比如groupid, 常用的id可用缩写替代：比如
源代码及文档管理规范
源代码管理文档管理规范 第一章总则 第一条为保障公司源代码和开发文档安全，保证源代码的完整，明确源代码控制管理流程，特制定本源代码管理办法。 第二条本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 第三条源代码直接控制管理部门为产品管理。原代码的内容为我单位万网工程建站的所有相关网站，模板，四川机构网网站代码以及数据库等。 第四条本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 第五条本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 第二章源代码完整性保障 第六条所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 第三章源代码的授权访问 第七条源代码服务器对于共享的TFS库的访问建立操作系统级的，基于身份和口令的访问授权。 第八条在TFS库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接TFS库时必须校验TFS中用户身份及其口令。在TFS库中要求区别对待不同用户的可访问权、可读权、可写权。 第九条曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 第四章源代码复制和传播 第十条源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录
复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 第十一条源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。 第十二条源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十三条任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十四条对于因合作需要，需要向外复制、传播、分发源代码的，不论是全部还是部分代码和资料，均必需和对方签订技术、源码的保密协定，明确对方应当承担的对源码保密的责任和义务。 第十五条所有已有的开发文档与当前的代码进行统一管理。 第十六条新开发的项目和系统验收时必须与同相关的开发文档同时进行验收。 第五章开发文档管理规范 第十七条所有已有的开发文档与当前的代码进行统一管理 第十八条本规范执行日之后的所有项目的开发必须按开发的基本规则输出开发文档进行备案。 第十九条开发周期在1-3个月以内的项目开发文档保密时效为6个月，开发周期在3个月以上的为一年，保密时效计时为项目结束成功验收之后开始。 第二十条在项目开发中任何以不得未经授权向外发布、流传开发相当的任何文档。
软件公司-源代码管理制度资料
软件公司-源代码管理 制度
源代码管理制度（讨论稿） 一、总则 为了加强公司产品、项目开发源代码及相关技术文档的管理，进而确保项目实施的效率和质量，特制定本办法。 二、适用范围 产品、项目开发技术人员及项目实施负责人。 三、定义 项目：是指通过公司立项确定需要按期实施的项目。 项目实施：是指为完成立项项目进行的阶段性或特定领域的实施过程，主要包括研发实施和部署实施。 源代码：是指产品、项目研发过程中所产生的程序源代码。 技术文档：是指产品、项目配套的各类设计文档、操作手册等技术性文档。 版本管理服务器：指公司架设供所有开发人员使用的Subversion(SVN)服务器。 源代码提交：指开发人员通过客户端程序将所编写源代码上传至版本管理服务器的操作过程。 四、源代码日常管理流程 源代码管理是技术研发过程的日常管理，主要包括源代码提交、源代码审阅、异常协调等几个环节。
否 五、源代码结构设定 源代码结构是指源代码在版本管理服务器上存放的文件夹结构。源代码结构的设定由项目实施负责人决定。 源代码结构设定有几项基本要求： ?必须设置文档文件夹：每一个独立项目或子项目源代码文件内，至少设定一个docs或doc文件夹以存放仅与该项目相关技术文档和参考资料； ?必须考虑支持库：源代码结构中，应考虑具体项目所引用的非标 第三方支持库或框架的存放位置；
?必须可以直接编译：源代码结构必须是可直接编译结构。即任何一台新装计算机，在安装了必要的开发环境软件以后，通过从版本管理服务器上签出整套源代码后，应该可以直接完成编译。六、500提交 500提交是指项目实施期间，所有参与开发的技术人员，每日5:00必须将当日所编制的源码或技术文档提交至版本管理服务器。源代码及技术文档提交有如下几项要求： ?任何一次提交都必须对所提交内容进行注释； ?提交注释必须包含的信息项包括：所属模块或功能（必须与项目实施进度计划一致）、性质（正常开发、修改BUG、扩展功 能）、状态（编码中（x%）、调试通过、独测通过、联测通 过）、更新说明（本次提交所涉及修改部分的简要说明）。 ?提交注释必须以下图示例格式为准。 ?所提交源码必须是编译无错版本。 七、530审阅 530审阅是指项目实施负责人，每日下班前审阅版本服务器上所有下属技术人员所提交的源代码和技术文档。 源代码审阅有以下几点审阅标准：