PEP8Python编码规范.doc

PEP8Python编码规范.doc
PEP8Python编码规范.doc

PEP8 Python 编码规范

1代码编排

1.1 缩进。 4 个空格的缩进(编辑器都可以完成此功能),不使用 Tap,更不能混合使

用 Tap 和空格。

1.2 每行最大长度 79,换行可以使用反斜杠,最好使用圆括号。换行点要在操作符的

后边敲回车。

1.3 类和 top-level 函数定义之间空两行;类中的方法定义之间空一行;函数内逻辑无

关段落之间空一行;其他地方尽量不要再空行。

2文档编排

2.1 模块内容的顺序:模块说明和docstring — import — globals&constants —其他定义。

其中 import 部分,又按标准、三方和自己编写顺序依次排放,之间空一行。

2.2 不要在一句 import 中多个库,比如 import os, sys 不推荐。

2.3 如果采用 from XX import XX 引用库,可以省略‘ module. ’,都是可能出现命名冲

突,这时就要采用 import XX 。

3空格的使用

总体原则,避免不必要的空格。

3.1 各种右括号前不要加空格。

3.2 逗号、冒号、分号前不要加空格。

3.3 函数的左括号前不要加空格。如Func(1)。

3.4 序列的左括号前不要加空格。如list[2] 。

3.5 操作符左右各加一个空格,不要为了对齐增加空格。

3.6 函数默认参数使用的赋值符左右省略空格。

3.7 不要将多句语句写在同一行,尽管使用‘;’允许。

3.8 if/for/while 语句中,即使执行语句只有一句,也必须另起一行。

4注释

总体原则,错误的注释不如没有注释。所以当一段代码发生变化时,第一件事就

是要修改注释!注释必须使用英文,最好是完整的句子,首字母大写,句后要有结

束符,结束符后跟两个空格,开始下一句。如果是短语,可以省略结束符。

4.1块注释,在一段代码前增加的注释。在‘ #’后加一空格。段落之间以只有‘#’的行间

隔。比如:

#Description : Module config.

#

#Input : None

#

# Output : None

4.2行注释,在一句代码后加注释。比如:x = x + 1# Increment x

但是这种方式尽量少使用。

4.3避免无谓的注释。

5文档描述

5.1 为所有的共有模块、函数、类、方法写docstrings ;非共有的没有必要,但是可以

写注释(在 def 的下一行)。

5.2 如果 docstring 要换行,参考如下例子,详见 PEP 257

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first.

"""

6命名规范

总体原则,新编代码必须按下面命名风格进行,现有库的编码尽量保持风格。

6.1 尽量单独使用小写字母‘ l ’,大写字母‘ O’等容易混淆的字母。

6.2 模块命名尽量短小,使用全部小写的方式,可以使用下划线。

6.3 包命名尽量短小,使用全部小写的方式,不可以使用下划线。

6.4 类的命名使用CapWords 的方式,模块内部使用的类采用_CapWords 的方式。

6.5 异常命名使用CapWords+Error 后缀的方式。

6.6 全局变量尽量只在模块内有效,类似 C 语言中的 static。实现方法有两种,一是

__all__机制 ;二是前缀一个下划线。

6.7 函数命名使用全部小写的方式,可以使用下划线。

6.8 常量命名使用全部大写的方式,可以使用下划线。

6.9 类的属性(方法和变量)命名使用全部小写的方式,可以使用下划线。

6.10 类的属性有 3 种作用域 public 、 non-public 和 subclass API,可以理解成C++中的

public 、private 、 protected , non-public 属性前,前缀一条下划线。

6.11 类的属性若与关键字名字冲突,后缀一下划线,尽量不要使用缩略等其他方式。

6.12 为避免与子类属性命名冲突,在类的一些属性前,前缀两条下划线。比如:类 Foo

中声明 __a,访问时,只能通过Foo._Foo__a,避免歧义。如果子类也叫Foo,那就

无能为力了。

6.13 类的方法第一个参数必须是self,而静态方法第一个参数必须是cls。

7编码建议

7.1 编码中考虑到其他python 实现的效率等问题,比如运算符‘+’在 CPython( Python )

中效率很高,都是Jython 中却非常低,所以应该采用 .join() 的方式。

7.2 尽可能使用‘ is’‘ is not ’取代‘ ==’,比如 if x is not None 要优于 if x。

7.3 使用基于类的异常,每个模块或包都有自己的异常类,此异常类继承自 Exception。

7.4 异常中不要使用裸露的 except, except 后跟具体的 exceptions。

7.5 异常中 try 的代码尽可能少。比如:

try:

value = collection[key]

except KeyError:

return key_not_found(key)

else:

return handle_value(value)

要优于

try:

# Too broad!

return handle_value(collection[key])

except KeyError:

#Will also catch KeyError raised by handle_value()

return key_not_found(key)

7.6 使用 startswith() and endswith() 代替切片进行序列前缀或后缀的检查。比如:

Yes: if foo.startswith('bar'): 优于

No: if foo[:3] == 'bar':

7.7 使用 isinstance()比较对象的类型。比如

Yes: if isinstance(obj, int): 优于

No: if type(obj) is type(1):

7.8 判断序列空或不空,有如下规则

Yes: if not seq:

if seq:

优于

No: if len(seq)

if not len(seq)

7.9 字符串不要以空格收尾。

7.10 二进制数据判断使用if boolvalue 的方式。

软件系统JAVA开发编码规范V1.0

软件系统JAVA 编码规范 版本V1.0

文档信息: 内容范围: 本文档是软件系统JAVA编码规范。适用的对象: 公司相关技术人员。

目录 1 介绍(INTRODUCTION) (5) 2 2 文件名(FILE NAMES) (6) 2.1文件后缀(F ILE S UFFIXES) (6) 2.2常用文件名(C OMMON F ILE N AMES) (6) 3 文件组织(FILE ORGANIZATION) (7) 3.1J AVA源文件(J AVA S OURCE F ILES) (7) 3.1.1开首注释(B EGINNING C OMMENTS) (7) 3.1.2包和引入语句(P ACKAGE AND I MPORT S TATEMENTS) (8) 3.1.3类和接口声明(C LASS AND I NTERFACE D ECLARATIONS) (8) 4 缩进排版(INDENTATION) (9) 4.1行长度(L INE L ENGTH) (9) 4.2换行(W RAPPING L INES) (9) 5 注释(COMMENTS) (13) 5.1实现注释的格局(I MPLEMENTATION C OMMENT F ORMATS) (13) 5.1.1块注释(B LOCK C OMMENTS) (13) 5.1.2单行注释(S INGLE-L INE C OMMENTS) (14) 5.1.3尾端注释(T RAILING C OMMENTS) (15) 5.1.4行末注释(E ND-O F-L INE C OMMENTS) (15) 5.2文档注释(D OCUMENTATION C OMMENTS) (16) 6 声明(DECLARATIONS) (17) 6.1每行声明变量的数量(N UMBER P ER L INE) (17) 6.2初始化(I NITIALIZATION) (17) 6.3布局(P LACEMENT) (17) 6.4类和接口的声明(C LASS AND I NTERFACE D ECLARATIONS) (18) 7 语句(STATEMENTS) (20) 7.1简单语句(S IMPLE S TATEMENTS) (20) 7.2复合语句(C OMPOUND S TATEMENTS) (20)

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错,保持团队支持顺畅,系统长久使用后不至于紊乱,让管理者易于在众多对象中,获取所需或理清问题。 同时,定义标准程序也需要团队合作,讨论出大家愿意遵循的规范。随着时间演进,还需要逐步校订与修改规范,让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契,而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户,如数据库管理员、程序设计人员和程序开发人员,可以直观地辨识对象用途。而命名规则大都约定俗成,可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例,让用户混淆自定义对象和系统对象或关键词。 例如,存储过程不要以sp_或xp_开头,因为SQL SERVER的系统存储过程以 sp_开头,扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略,要让对象的用途直观易懂,但也不宜过长,造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定,数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。避免中文和保留关键字,做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串,而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范,通过后严格按照要求实施。例如:

软件配置项标识编码规则设计方案解读

软件配置项标识编码规则设计方案 刘宏 2011-9-18 Mail:lh@https://www.360docs.net/doc/064703259.html, 1.背景 1.1.服务外包中迁移 在服务外包中,难度较大的阶段为——服务外包的迁移工程。 服务迁移工程难度大的主要原因之一,是没有实施迁移前准备标准和迁移后的验收标准。也就是在服务成熟到何种程度——包括管理与技术成熟度,服务才能够向外包方进行迁移,以便发包方有效控制服务外包中的风险,达到服务外包的目的。 服务外包迁移前应达到的准备标准——包括管理标准与技术标准,技术标准是管理标准的基础。技术标准是在服务外包迁移中的必要条件,管理标准是服务外包迁移中的充分条件。 不同服务业务在外包迁移中,具有不同的技术标准,但是具有相同的管理标准——ISO20000规定了管理相关的内容。 因为不同的服务业务具有不同的服务技术标准要求,因此正对IT服务外包业务应根据业务的特点编制相关的技术标准要求。IT服务外包业务可以包括: ●IT系统基础平台维护服务外包 ●IT系统支撑环境维护服务外包 ●应用系统的维护服务外包 1.2.服务外包迁移标准内容 每类服务有可以分成:运营服务(一线服务)、支持性服务(二线服务)、变更性服务(三线服务)。 在IT服务外包中风险较大的是运营服务,因为运营服务一直是直接在客户的生产环境实施,一旦发生错误,有可能给客户造成无法挽回的损失。目前一般风险较大的运营服务,有客户自己承担,不进行外包。 支持性服务也是在客户生产环境实施,但是一般需要进行策划与实施结果测试。由于支

持服务具有一定的技术性,因此这种服务外包迁移前应按照技术标准要求通过验收。只有通过技术标准验收的服务才能够实施服务外包的迁移。 变更性服务是在其他环境中测试完成后,在反映到生产环境中。因此变更性服务与系统建设期的系统开发存在不同的风险。在系统建设期,可以进行充分的测试与试运行测试。在变更性服务由于工期与成本的原因,可能不能充分进行测试与试运行。 1.3.服务外包迁移中标准需求 服务外包方为了及时提供服务需要将分包方的技术成果迁移到外包方处,因此分包方向服务外包方进行服务迁移时,在服务迁移时,迁移哪些内容,迁移的内容在迁移前应到技术标准要求应进行验证与确认。若是没有达到服务外包迁移技术标准,很显然是增加服务外包迁移的风险。 在服务外包迁移实施中,需要对服务外包迁移内容结果进行验证,因此需要服务外包迁移结果验证与确认的技术标准要求。 1.4.应用软件服务迁移标准需求分析 在应用软件系统维护服务外包的迁移中,技术标准主要是针对分包方迁移给外包方的所有技术成果物。对这些成果物需要相关的技术标准要求,以便在服务外包迁移过程,分包方与外包方能够有效沟通与交接,确保服务能够连续,不因为服务外包迁移发生中断或服务水平下降。 为了确保分包方与外包方能够有效进行技术沟通,首先需要明确出工程成果物的标识标准——配置项标识编码标准。这一标准能够是双方能够正确地在配置管理库中找到所需要的配置项。 为了能够有效避免交付过程中,使用错误的成果物。就需要双方共同承认的成果物的编码规则或标准。 由此得出结论:软件配置项标识编码规则,是IT应用系统维护服务外包的技术标准中的基础。 2.方案的目的与目标 2.1.目的 通过提供一般软件配置项编码规则,为企业的软件配置项的管理提供自动化处理的解决

项目编码规范

项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中,所有项目中的JAVA代码(含JSP,SERVLET,JAVABEAN,EJB)JS代码、HTML代码及数据库设计均应遵守这个规范。同时,也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解,方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥,将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能,原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时,如果所有方法都放在单个类中或者放在几十个类中,这没有任何关系。虽然类的数量对代码的执行并无太大的影响,但是当创建便于调试和维护的代码时,类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时,该类可以说具有强大的内聚力。当类包含许多互不相关的方法时,该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下,可以为这些不合群的方法创建一个综合性收容类。 创建类时,应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务,它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时,称为与其他方法紧密连接的方法。紧密连接的方法

华为软件开发规范

软件开发规范 1 排版 11-1:程序块要采用缩进风格编写,缩进的空格数为4个。 说明:对于由开发工具自动生成的代码可以有不一致。 11-2:相对独立的程序块之间、变量说明之后必须加空行。 示例:如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3:较长的语句(>80字符)要分成多行书写,长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐,语句可读。 示例: = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied

= stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));

工程项目编码规则及管理办法

中船重工船业有限公司工程项目编码规则及管理办法 1. 范围 本办法规定公司各种工程编码分类和编码实施规则及其管理办法。 本规则适用于公司内部所有工程项目的编码计划编制、领发料、财务核算、计算机信息处理等。 2. 工程编码类别及其编制规则说明 2.1工程编码类别分为船舶产品工程、非船产品工程、基建工程、自营工程、设备大修、设备维修、设备技改、安全设施及其它工程。 2.2产品工程编码的编制方法 2.2.1 大吨位运输船舶(千吨位以上)工程号的编制方法 2.2.1.1 编码共6 位。前两位为船舶产品载重吨位或承载体积前两位数;第三位为同载重吨位船舶型号,无型号用0 表示,有型号时分为Ⅰ型、Ⅱ型、Ⅲ型等,分别用1、2、3表示,以此类推;第四、五、六位为公司大吨位运输船舶接单顺序号。 2.2.1.2 图示

例如:公司接单第31 艘70000 吨散货船工程编码为:700031 。 公司接单第18 艘33000 吨散货Ⅰ型船工程编码为:331018 。 2.2.2 商务船工程号的编制办法 2.2.2.1 编码共6位。前两位统一名称为SW(商务);第三、四两位为商务船的长度,五、六两位为商务船接单顺序号。 2.2.2.2 图示 例如:公司接单第1 艘35 米长的商务船,工程号为:SW3501 2.2.3 小吨位(百吨位)运输船工程号的编制办法 2.2. 3.1 编码共6 位。前两位统一名称为YS(运输);第三、四两位为运输船的吨位前两位,五、六两位为公司小吨位运输船接单顺序号。 2.2. 3.2 图示 例如:公司接单第1 艘载重吨为20 吨的运输船,工程号:YS2001

软件开发工作规范章程

软件开发工作规范章程 Document serial number【KK89K-LLS98YT-SS8CB-SSUT-SST108】

软件开发工作规范章程 编写目的 本文档是开发团队的日常工作规范,主要侧重开发工作流程的控制,明确软件工程的各阶段开发团队应完成的工作。开发技术和策略等问题不在本文档描述范围内。开发团队构成 1.1职责 肩负着如下责任: 负责开发项目的系统分析、研发与组织实施。 负责开发符合要求的软件。 制定软件开发规范。 协助相关应用软件的安装调试工作。 1.2角色划分 在人力资源有限的情况下,一个团队成员可能会同时承担多个角色。 角色名称相关主要责任 开发组长负责研发团队建设 负责研发项目的工作分工、实施、监控及后续完善工作 参与确定研发产品的种类,并制定研发产品的相关标准及研发工作计划 负责技术路线与方向 完成研发过程中的其他任务 超出能力权限向上一级汇报 根据项目情况,向所属组制定技能提升计划并实施 特性负责人负责研发特性的工作分工、实施、监控及后续完善工作 制定特性的软件开发技术规范及研发工作计划

负责《详细设计》的编写。 按期、按预算交付高质量的产品 建设有凝聚力团队环境,并促使高效的团队协作 负责软件实施规范执行 根据开发规范实施开发工作 软件的程序设计、代码编写与单元测试。 协助《详细设计》的编写。 承担开发任务,按计划完成任务目标。 配合系统分析人员完成软件系统以及模块的需求调 研、需求分析。 协助测试人员完成软件系统及模块的测试。 1.3需求澄清 1.4编码阶段 1.4.1开发规范

1.4.2开发环境准备 1.4.3详细设计 1.4.4编码

软件设计编码规范

质量管理体系过程文件 软件设计编码过程 文件版本信息:

目录 1.目的 设计编码的目的在于设计和实现关于需求的解决方案。保证《需求规格说明书》中的各项要求在设计时都能够得到满足;对项目的编码实现进行质量控制,保证编码实现活动按计划顺利完成并与设计相一致。 2.范围 适用于公司的各类软件项目的系统设计编码过程。 3.术语 无 4.角色与职责

5.入口准则 ●《需求规格说明书》已通过评审。 6.输入 ●《需求规格说明书》 7.流程图 图1: 系统设计编码过程 8.主要活动 系统设计编码过程包括系统设计、系统实现。系统设计是指设计软件系统的体系结构、数据库、模块等,在需求和代码之间建立桥梁,一般分概要设计和详细设计两个阶段;系统实现是指开发人员按照系统设计去编码开发,并进行单元测试、代码走查;在设计编码过程中同时进行用户文档的编制。 8.1.概要设计 概要设计是分析各种设计方案和定义软件体系结构的过程。设计人员在充分了解需求的基础上,依据《需求规格说明书》选用适当的设计方法,分析与设计软件的结构、模块功能。通过系统分解,确定子系统的功能和子系统之间的关系,以及模块的功能和模块之间的关系,编写《概要设计说明书》。《概要设计说明书》必须经过技术评审。 8.1.1.解决方案选择 系统设计时可能会涉及到多种解决方案的选择,如: ●系统实现路线; ●采用的工具和技术; ●产品架构; ●设计模式; ●模块的制作、购买或重用等。 当出现多种候选方案,难以通过简单的方法判断出方案的优劣时,应按照《S_DAR00_决策分析和决定过程》进行决策。

8.1.2.概要设计 概要设计是建立整个软件的体系结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义等。概要设计的主要步骤有: ?选择设计方法; ?识别解决方案的主要组件:根据解决方案的技术架构和分析方法(面向对象、面向结 构),相应确定解决方案的组件模块; ?对候选技术和工具、组件进行评估,确定是进行开发、购买还是复用已有技术(工具 或者组件)。评估开发、购买或复用方案时需要考虑的事项包括:业务方面:可行性、产品成本、经验、投资回报、成熟度及其他因素;企业体系结构方面:解决方案必须 与当前状态和远景状态计划的约束相适应。包括与企业现有系统的集成等;技术方面:安全、组件模块交互标准、数据访问、数据存储、系统服务、开发工具、操作系统等。 ?识别解决方案主要组件的重要属性和关键关系:在前一任务的基础上,对解决方案主 要组件的重要属性和关键关系进行识别; ?进行数据库设计,建立数据库的逻辑模型和物理模型; ?进行用户界面设计,确定整个系统的界面框架以及界面风格; ?形成《概要设计说明书》。 8.1.3.概要设计评审 概要设计的结果应进行技术评审。技术评审由设计人员提出,由项目经理组织召开。技术评审会议应邀请需求分析师、公司的技术专家、开发人员、测试人员等参加。 关于技术评审会议的要求详见《评审过程》。 8.2.详细设计 详细设计可以和概要设计并行进行,但应考虑并行设计不会因概要设计而导致较大的详细设计返工。 8.2.1.详细设计 详细设计是从开发需求的角度描述解决方案的组件、服务和技术的过程。详细设计定义了解决方案的各个组成部分,以及这些组成部分的开发方法和交互方式。详细设计的步骤包括: ?选择用于开发解决方案的技术并完善设计模型:在概要设计的基础上,选择开发解决 方案采用的技术,并且完善对应的设计模型。

软件开发代码规范(Java)

软件开发代码规范(C) (仅通普信息技术股份有限公司供内部使用) 拟制:杨超日期:2015-3-10审核:夏峰日期:2015-3-10核准:冯敬刚日期:2015-3-17签发:韩殿成日期:2015-3-21文档版本:V1.11 黑龙江通普信息技术股份有限公司

版本历史

目录 第一章代码开发规范及其指南 0 1.1目的 0 1.2程序内命名规范 0 1.3文件命名规范 (1) 1.4J AVA 文件样式 (1) 1.5代码编写格式 (6) 第二章程序编写规范方法 (8) 2.1权限修饰 (8) 2.2其他规范 (8) 2.3编程指南 (10) 第三章其他要求 (12)

第一章代码开发规范及其指南 1.1 目的 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的,增加可读性,减少项目组中因为换人而带来的损失。(这些规范并不是一定要绝对遵守,但是一定要让程序有良好的可读性) 1.2 程序内命名规范 ●Package的命名:Package 的名字应该都是由一个小写单词组成。 ●Class 的命名:Class 的名字必须由大写字母开头而其他字母都小写的单词组 成 ●Class 变量的命名:变量的名字必须用一个小写字母开头。后面的单词用大 写字母开头。 ●Static Final 变量的命名:Static Final 变量的名字应该都大写,并且指出完整 含义。 ●参数的命名:参数的名字必须和变量的命名规范一致。 ●数组的命名:数组应该总是用下面的方式来命名: byte[] buffer; 而不是 byte buffer[]; ●方法的参数:使用有意义的参数命名,如果可能的话,使用和要赋值的字 段一样的名字: SetCounter(int size){ this.size = size;

【编号规则】工程信息编码标准

QB ****公司企业标准 信息分类和编码 第3分册工程信息分类和编码 (初稿) 20XX-XX-XX 发布 20XX -XX -XX 发行 *****有限责任公司 发 布 ICS XXX 备案号XXX

目次 前言 (3) 引言 (4) 1范围 (5) 2规范性引用文件 (5) 3术语和定义 (5) 4分类原则和方法 (6) 4.1基本原则 (6) 4.2分类对象的层面划分 (6) 4.3工程信息分类 (7) 4.4工程信息整体框架 (8) 5编码方法 (9) 5.1基本原则 (9) 5.2码值 (9) 5.3代码组结构和层次 (10) 5.3.1交互定位码 (10) 5.3.2项目编码 (10) 5.3.3管理属性编码 (11) 5.3.4设计属性编码 (11) 5.3.5合同属性编码 (12) 5.3.6档案属性编码 (12) 5.3.7采购、财务、招标信息属性编码 (13) 5.3.8非项目信息编码 (13) 6分类与代码表 (14) 6.1非项目信息分类标识码(30301) (14) 6.2省电网公司及直属单位编码(30302) (14) 6.3工程项目建设管理单位代码(30303) (15) 6.4项目属性代码(30304) (18) 6.5综合指标(30305) (19) 6.6立项时间(30306) (20) 6.7批次项目标识码(30307) (21) 6.8信息属性码分类(30308) (21) 6.9项目阶段代码((30309) (22) 6.10工作分解代码(30310) (22) 6.11信息创建部门代码(30311) (23) 6.12设计资料分类代码(30314) (24) 6.13设计阶段代码(30315) (24) 6.14类目代码(30316) (25)

软件开发代码规范(C#版)

软件开发代码规范(C#版) 拟制: 日期:2007-2-13 审核: 日期: 审核: 日期: 批准: 日期: 版权所有********有限公司

修订纪录

目录 1、第一章命名规范 (4) 1.1、第一节总则 (4) 1.2、第二节变量命名规范 (4) 1.2.1、CodeBehind内部命名规范 (4) 1.2.2、控件命名规范 (5) 1.3、第三节常量命名规范 (5) 1.4、第四节命名空间、类、方法命名规范 (5) 1.5、第五节接口命名规范 (6) 1.6、第六节命名规范小结 (6) 2、第二章代码注释规范 (6) 2.1、第一节模块级注释规范(命名空间、类等) (6) 2.2、第二节方法级注释规范 (7) 2.2.1 、属性注释 (7) 2.2.2 、方法注释 (7) 2.3、第三节代码间注释规范 (8) 3、第三章编写规范 (9) 3.1、第一节格式规范 (9) 3.2、第二节编程规范 (9) 3.2.1 、程序结构要求 (9) 3.2.2 、可读性要求 (10) 3.2.3 、结构化要求 (10) 3.2.4 、正确性与容错性要求 (10) 3.2.5 、可重用性要求 (11) 3.2.6 、interface使用注意事项 (11) 3.2.7 、类使用注意事项 (11) 3.2.8 、流程控制语句注意事项 (12) 3.2.8 、其他应注意事项 (13) 注:Pascal命名法则:即名称中所有单词的第一个字母大写其他字母使用小写形式。 Camel命名法则:即名称中第一个单词各个字母全部小写,其他部分遵循Pascal命名法则。

1、第一章命名规范 1.1、第一节总则 1.本命名规则除特殊提及外统一使用Camel命名法则。 如:controlMenu 2.命名时尽量不使用拼音,更不可使用拼音缩写(专有名词除外)。 3.如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如:LuX则命名时,不要写成LUX,或者Lux,而应该保持与原品牌名称风格一致使用LuX 4.使用专有名词或英文缩写命名时采用大写形式。 如:CNNIC 5.禁止使用仅区分大小写的方式命名。 如:Abc与abc仅用大写A来区分,这样写在类C系语言中不会出错,但是不利于系统的迁移 1.2、第二节变量命名规范 1.2.1、CodeBehind内部命名规范 1.公有字段/属性使用Pascal 命名规则,私有变量/保护变量/局部变量使用Camel命名规则,遵循动宾结构。 例: public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return https://www.360docs.net/doc/064703259.html,erName; } } } 2.即使对于可能仅出现在几个代码行中的生存期很短的变量,仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名,如i 或j 3.在变量名中使用互补对,如Min/Max、Begin/End 和Open/Close。 4.当一个方法内部变量繁多的时候,可以使用Camel命名法则,其中第一个单词可以使用变量类型的缩写来说明以示区别。 例:

软件开发管理规范

软件开发管理规范 Document serial number【KK89K-LLS98YT-SS8CB-SSUT-SST108】

软件开发过程管理规范济南明湖建筑节能技术开发有限公司

一、总则 1.软件开发项目管理的目的 为保障按时、保质、保量完成预期交付的任务,让整个组织能清楚了解项目实施的目的、影响、进度,做到项目组所有成员都理解项目实施的原因、意义及客户的要求。通过制度化管理来合理组织安排项目组成员的工作职责和角色转换。 2.软件开发项目管理规范适用对象 为了达到软件开发项目管理的根本目的,要求公司全体员工必须严格按照本规范执行,同时要求公司业务人员引导合作单位和客户接受并适应公司本《软件项目开发管理规范》。 3.软件项目开发组织管理 根据软件开发的标准流程,结合公司的实际情况对软件项目分三个主要阶段进行组织管理,分别为项目立项阶段、项目实施阶段和项目验收总结阶段。 二、软件项目立项阶段 1.成立公司项目评估委员会负责公司的项目立项审批。 2.公司项目评估委员会由公司总经理或指定负责人召集,成员为公司管 理层人员、商务负责人、市场负责人、技术总监、技术研发经理、财务负责人组成。 3.公司业务部门按照公司发展要求或外部需求形成《软件项目需求说明 书》,确定项目需求管理人或项目申请人。 4.项目申请人填写《软件项目立项申请书》向项目评估委员会提出项目

立项申请,主要说明项目的背景、目的、效益、成本、需求等方面,并由技术部门提供支持和技术说明。 5.项目评估委员会收到《项目立项申请书》后三个工作日内,召开评估 会议。给出评估结果。如果批准立项交公司技术总监组织开发。如果不批准,给出理由后项目中止。中止后的项目可根据情况重新申请。 6.评估结果必须包括:建议项目启动日期,期望项目完成日期,项目等 级系数,项目优先级(高中低),资源冲突程度(1~9)。对于资源冲突程度大于5的项目技术总监有权拒绝接受。 三、软件项目实施阶段 1.公司批准立项的项目交由公司技术总监组织实施。 2.技术总监根据资源情况和项目需求组织相关技术人员进行初步需求讨 论会,确定项目的等级系数(如分大、中、小对应3、2、1)、指定项目开发负责人。在立项后五个工作日内技术总监和项目开发负责人共同制定《软件项目开发计划》,确定项目启动日并提交项目评估委员会做反馈确认。如果项目评估委员会二位成员以上对计划有异议,项目评估委员会应该召开项目计划协调会,协调《软件项目开发计划》的修改和通过。如果无异议授权技术总监按照《软件项目开发计划》执行。 3.项目启动日后,项目开发负责人根据《软件项目开发计划》的进度每 周进行一次分析汇报,形成《项目分析周报》确定项目的状态、分析

软件设计编码规范标准[详]

质量管理体系过程文件软件设计编码过程

文件版本信息:

目录 1.目的 (3) 2.围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (3) 8.主要活动 (4) 8.1.设计原则 (4) 8.2.设计方法.................................................................................... 错误!未定义书签。 8.3.多方案选择 (4) 8.4.概要设计.................................................................................... 错误!未定义书签。 8.4.1.概要设计............................................................................ 错误!未定义书签。 8.4.2.概要设计评审.................................................................... 错误!未定义书签。 8.5.详细设计.................................................................................... 错误!未定义书签。 8.5.1.详细设计 (5) 8.5.2.详细设计评审 (6) 8.6.编码............................................................................................ 错误!未定义书签。 8.7.单元测试 (7) 8.8.代码走查 (7) 8.9.制作用户文档............................................................................ 错误!未定义书签。 8.10.变更............................................................................................ 错误!未定义书签。 9.输出 (8) 10.出口准则 (8) 11.引用文档 (8)

项目编码规范编写指南

项目编码规范 1 命名规范 1).包名采用域后缀倒置的加上自定义的包名,采用小写字母。 在部门内部应该规划好包名的范围,防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。 格式: com.huawei.产品名.模块名称 com.huawei.部门名称. 项目名称 示例: Relay模块包名 com.huawei.msg.relay 通用日志模块包名 com.huawei.msg.log 2). 类名和接口使用类意义完整的英文描述,每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。 示例: OrderInformation, CustomerList, LogManager, LogConfig 3). 方法名使用类意义完整的英文描述:第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。 示例: private void calculateRate(); public void addNewOrder(); 4). 方法中,存取属性的方法采用setter 和 getter方法,动作方法采用动词和动宾结构。格式: get + 非布尔属性名() is + 布尔属性名() set + 属性名() 动词() 动词 + 宾语() 示例: public String getType(); public boolean isFinished(); public void setVisible(boolean); public void show();

public void addKeyListener(Listener); 5).属性名使用意义完整的英文描述:第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。 示例: private customerName; private orderNumber; private smpSession; 6). 常量名使用全大写的英文描述,英文单词之间用下划线分隔开,并且使用 final static 修饰。 示例: public final static int MAX_VALUE = 1000; public final static String DEFAULT_START_DATE = "2001-12-08"; 7). 属性名可以和公有方法参数相同,不能和局部变量相同,引用非静态成员变量时使用 this 引用,引用静态成员变量时使用类名引用。 示例: public class Person { private String name; private static List properties; public void setName (String name) { https://www.360docs.net/doc/064703259.html, = name; } public void setProperties (List properties) { Person.properties = properties; } } 8).如果函数名超过15 个字母,可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。 示例: getCustomerInformation() 改为 getCustomerInfo() 2 程序注释规范 1)、基本注释(必须加)

某公司软件开发中的标识规范标准

标识规范 沈阳东大阿尔派软件股份有限公司(版权所有,翻版必究)

文件修改控制

目录 1. 目的 2. 适用范围 3. 术语和缩略语 4. 标识规则 4.1 标识对象 4.2 文档版本控制 4.3 发行版本控制 4.4 软件项标识方式 4.5 不合格品的标识 5. 引用文件 5.1 NW602102《文件编号规定》 6. 质量记录 6.1 NR602101A“文件备份清单”

1.目的 为便于标识、控制和追踪软件开发过程中产生的各种软件项及介质,特制定本文件。 2.适用范围 适用于软件开发过程中所需的各种软件项及介质。 3.术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 4.标识规则 4.1 标识对象 标识对象主要包括:技术文档(可行性分析报告、需求分析报告、开发计划、质 量计划、系统设计报告、技术报告、测试计划等)、提交产品(计算机程序、释 放产品等),主要通过介质标识和版本控制以便于存取和查阅。 4.2 文档版本控制 对于计划性文档、技术文档和用户文档,其版本按修改的先后顺序确定。新生成 的文档第一次发行为第一版,修改后第二次发行为第二版,以此类推。 4.3 发行版本控制 最终完成的软件版本用三位符号表示:“s.xy”。各符号位的含义如下: 1)“y”为第二次版本号,表示纠正错误时的版本升级,用一位数字表示:“1~9”,对上一次产品或项目中的缺陷做修正,第二次版本号增加;

2)“x”为第一次版本号,表示增加功能时的版本升级,用一位数字表示:“0~9”。与上一产品或项目相比,功能进行了小量的增加或修正时,第一次 版本号增加,第二次版本号为零,第二版本号为零时可以省略不写; 3)“s”为主版本号,用一位数字表示:“1~9”。对产品作重大调整,或与已发行的上一产品相比,在功能与性能上有较大改善时主版本号增加,次版本号 为零,产品或项目概念全新,第一次完成,版本号为1.0。 4.4 软件项标识方式 4.4.1 技术文档标识方式 技术文档的标识体现在相应文件的封面上,由开发人员参照相应文档模板的格式 要求,对技术文档进行标识。 技术文档编号用十五位符号表示:“xxxxxxxxxxxttnn”。各符号位的含义如下:1)“xxxxxxxxxxx”为本次开发的项目编号,共十一位,具体含义见NW602102《文件编号规定》; 2)“tt”为文档类别代号,用两位大写字母表示。“tt”的取值范围如下:FA(Feasibility Analysis):可行性分析报告 RA(Requirement Analysis):需求分析报告 DP(Developing Plan):开发计划 QP(Quality Plan):质量计划 SD(System Design):系统设计报告 TR(Technical Report):技术报告 SR(Summary Report):项目开发总结报告 本部分未给出代号的文档,其代号由相应的文档编写部门确定。

软件编码规范.doc

软件编码规范 中国人民银行清算总中心 支付系统开发中心

注:变化状态:A—增加,M—修改,D—删除

目录 第一篇C/C++编码规范 (6) 第一章代码组织 (6) 第二章命名 (9) 2.1文件命名 (9) 2.2变量命名 (9) 2.3常量与宏命名 (10) 2.4类命名 (10) 2.5函数命名 (10) 2.6参数命名 (11) 第三章注释 (12) 3.1文档化注释 (12) 3.2语句块注释 (17) 3.3代码维护注释 (20) 第四章编码风格 (22) 4.1排版风格 (22) 4.2头文件 (26) 4.3宏定义 (27) 4.4变量与常量 (30) 4.5条件判断 (32) 4.6空间申请与释放 (33) 4.7函数编写 (33) 4.8类的编写 (37) 4.9异常处理 (40) 4.10特殊限制 (40) 第五章编译 (41) 第六章ESQL/C编码 (46) 第二篇JAVA编码规范 (47) 第一章代码组织 (48) 第二章命名 (51) 2.1包命名 (51) 2.2类命名 (51) 2.3接口命名 (51) 2.4方法命名 (51) 2.5变量命名 (51) 2.6类变量命名 (52) 2.7常量命名 (52) 2.8参数命名 (52) 第三章注释 (53) 3.1文档化注释 (53) 3.2语句块注释 (57) 3.3代码维护注释 (59) 第四章编码风格 (61) 4.1排版风格 (61) 4.2包与类引用 (66) 4.3变量与常量 (66) 4.4类编写 (67) 4.5方法编写 (68)

4.6异常处理 (71) 4.7特殊限制 (71) 第五章编译 (73) 第六章JSP编码 (74) 6.1文件命名及存放位置 (74) 6.2内容组织 (74) 6.3编码风格 (76) 6.4注释 (78) 6.5缩进与对齐 (78) 6.6表达式 (79) 6.7JavaScript (79) 第三篇POWERBUILDER编码规范 (80) 第一章代码组织 (81) 第二章命名 (82) 2.1文件命名 (82) 2.2对象命名 (82) 2.3变量命名 (84) 2.4常量命名 (85) 2.5函数与事件命名 (85) 2.6参数命名 (85) 第三章注释 (85) 3.1文档化注释 (85) 3.2语句块注释 (88) 3.3代码维护注释 (88) 第四章编码风格 (89) 4.1界面风格 (89) 4.2排版风格 (93) 4.3变量与常量 (95) 4.4条件判断 (96) 4.5空间申请与释放 (97) 4.6函数编写 (97) 4.7特殊限制 (97) 第五章SQL编码 (98)

软件开发编码规范86601

"\n"。 HTML Tab。 作

遵循下面列出的准则有利于编写更加安全的代码。但是总体来说,这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践,但是即使遵循了这些准则,写出的代码仍然可能是不安全的。风险永远存在,不管在编写代码时是如何的警觉。 这些准则的目标,不是为了保证代码的安全性,而是为了消除若干特定类型攻击带来的风险。遵循这些准则,某些特定类型的攻击将无法实现;但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时,应当仔细的考虑如下准则: ?静态字段 ?缩小作用域 ?公共方法和字段 ?保护包 ?尽可能使对象不可变(immutable) ?序列化 ?清除敏感信息 1) 静态字段 避免使用非final的公共静态变量,应尽可能地避免使用非final公共静态变量,因为无法判断代码有无权限改变这些静态变量的值。 一般地,应谨慎使用可变的静态状态,因为这可能导致设想中应该相互独立的子系统之间发生不曾预期的交互。 2) 缩小作用域 作为一个惯例,尽可能缩小成员方法和成员变量的作用域。检查包访问权限成员(package-private)能否改成私有成员(private),保护访问成员(protected)可否改成包访问权限成员(package-private)/私有成员(private)等等。 3) 公共方法/字段 公共变量应当避免使用,访问这些变量时应当通过getter/setter法。在这种方式下,必要时可以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法,务必包含安全检查。 参考如下代码段,该代码段中不可信任代码可能修改TimeZone的值: private static TimeZone defaultZone = null; public static synchronized void setDefault(TimeZone zone) { defaultZone = zone;

ERP编码原则(范例)

ERP编码方案 一目的: 为了适应公司网络化的发展,使物料分类、编码标准统一,使ERP管理软件的实施运用有一个必备的基础,特制定此物料编码规则。 二适用范围及定义: 适用于公司所有产品, 所包含如下的内容:成品、半成品、原材料、客供料、外协料、辅料、其它 定义: 成品:在生产车间已包装的产品; 半成品:在公司生产车间或外协工厂至少经过一道加工工序后,需要入库登记帐的零件总称; 原材料:直接从外供应商购买且用于加工生产成品的主要生产材料; 外协件:1.在本公司没有加工工艺而需外协厂商配合第二次以上加工; 2.当外协件与原材料冲突时, 以外协件编码方式编码; 3.当原材料和外协料有冲突时,依原材料为准。 客供料:1)在满足客户订单产品的生产过程中,需用到客户提供的原材料; 2)为满足客户的供货运输需要,需要将客户所订其它公司的货品暂存公司仓库的成品或物料; 辅料:直接或间接用于产品的生产实施过程上,包括包装贮运过程,但用量不可定量的物料; 其它:在无法定义所属类别属性时的一个范围。 三权责: 3.1 推行小组:负责物料编码规则的制定、解释以及增补修订; 3.2 开发中心:a. 负责按编码规则对新物料编号并建立BOM及资料文档; b. 对编码有统一的行使操作权; 3.3 其它部门:严格按技术部的物料编码管理、使用物料,给出建议性意见; 四编码总则: 4.1 坚持一种物料对应一个编码; 4.2 编码有章可循,不会重复,便于实施; 4.3 编码应留有足够的可扩充空间,且有必要加以增加新规定时,被规定种类的物料已由原规则给定编码的,仍 然给用,新规定只适用于该种类新物料的编码; 4.4 编码应具有最大程度的直观性,便于查找、识别; 4.5 编码规则作修改时,应不影响以往的编码体系,避免同一物料重复编码; 4.6 编码由开发中心专人统一编码,同一物料只能有唯一的编码; 4.7 五成品编码说明:(A:表示字母;N:表示数字) 5.1针对止退片类: (1)编码第一位为产品大类码,对照表如下: (2)编码第二位为产品性质码,当编码第一位的编号是(1~2)成品的时候, 对照表如下:

相关文档
最新文档