个体软件过程与编码规范_第1页
个体软件过程与编码规范_第2页
个体软件过程与编码规范_第3页
个体软件过程与编码规范_第4页
个体软件过程与编码规范_第5页
已阅读5页,还剩13页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

个体软件过程与编码规范篇一:java 代码规范详细版Java 代码规范 本 Java 代码规范以 SUN 的标准 Java 代码规范为基础,为适应我们公司的实际需要,可能会做一些修改。本文档中没有说明的地方,请参看 SUN Java 标准代码规范。如果两边有冲突,以 SUN Java 标准为准。 1. 标识符命名规范 概述 标识符的命名力求做到统一、达意和简洁。尽量做到每个人按照规范来,多人开发如一人开发一样。 统一 统一是指,对于同一个概念,在程序中用同一种表示方法,比如对于供应商,既可以用 supplier,也可以用provider,但是我们只能选定一个使用,至少在一个 Java项目中保持统一。统一是作为重要的,如果对同一概念有不同的表示方法,会使代码混乱难以理解。即使不能取得好的名称,但是只要统一,阅读起来也不会太困难,因为阅读者只要理解一次。 达意 达意是指,标识符能准确的表达出它所代表的意义,比如: newSupplier, OrderPaymentGatewayService 等;而 supplier1, service2,idtts 等则不是好的命名方式。准确有两成含义,一是正确,而是丰富。如果给一个代表供应商的变量起名是 order,显然没有正确表达。同样的,supplier1, 远没有 targetSupplier 意义丰富。 简洁 简洁是指,在统一和达意的前提下,用尽量少的标识符。如果不能达意,宁愿不要简洁。比如:theOrderNameOfTheTargetSupplierWhichIsTransfered 太长, transferedTargetSupplierOrderName 则较好,但是transTgtSplOrdNm 就不好了。省略元音的缩写方式不要使用,我们的英语往往还没有好到看得懂奇怪的缩写。 骆驼法则 Java 中,除了包名,静态常量等特殊情况,大部分情况下标识符使用骆驼法则,即单词之间不使用特殊符号分割,而是通过首字母大写来分割。比如: supplierName, addNewContract,而不是 supplier_name, add_new_contract。 英文 vs 拼音尽量使用通俗易懂的英文单词,如果不会可以向队友求助,实在不行则使用汉语拼音,避免拼音与英文混用。比如表示归档,用 archive 比较好, 用 pigeonhole 则不好,用 guiDang 尚可接受。 包名 使用小写字母如 ,不要 单词间不要用字符隔开,比如 ,而不要 _util 类名 首字母大写 类名要首字母大写,比如 LCIssueInfoManagerEJB, LCIssueAction;不要 lcIssueInfoManagerEJB, lcIssueAction. 后缀 类名往往用不同的后缀表达额外的意思,如下表: 参数和局部变量名首字母小写,骆驼法则。尽量不要和域冲突,尽量表达这个变量在方法中的意义。2. 代码格式 使用 tab 缩进源代码。 使用 alt+shift+f (eclipse)来格式化代码,注:格式化代码后还需手动来调下。 源文件编码 源文件使用 utf-8 编码,结尾用 unix n 分格。 行宽 行宽度不要超过 80。Eclipse 标准 包的导入 删除不用的导入,尽量不要使用整个包的导入。在eclipse 下经常使用快捷键 ctrl+shift+o 修正导入。 类格式 域格式 每行只能声明一个域。 域的声明用空行隔开。 方法格式 代码块格式 缩进风格 大括号的开始在代码块开始的行尾,闭合在和代码块同一缩进的行首,同一层次的代码要保持整齐,例如: 篇二:Verilog 代码编写规范Verilog 代码编写规范 有点东东,给大家一起分享一下: * Verilog 代码编写规范 一. 强调 Verilog 代码编写风格的必要性。 强调 Verilog 代码编写规范,经常是一个不太受欢迎的话题,但却是非常有必要的。 每个代码编写者都有自己的编写习惯,而且都喜欢按照自己的习惯去编写代码。与自己编写风格相近的代码,阅读起来容易接受和理解。相反和自己编写风格差别较大的代码,阅读和接受起来就困难一些。 曾有编程大师总结说,一个优秀的程序员,能维护的代码长度大约在 1 万行数量级。代码的整洁程度,很大程度上影响着代码的维护难度。 遵循代码编写规范书写的代码,很容易阅读、理解、维护、修改、跟踪调试、整理文档。相反代码编写风格随意的代码,通常晦涩、凌乱,会给开发者本人的调试、修改工作带来困难,也会给合作者带来很大麻烦。 (实际上英文 Coding Style 有另一层涵义,更偏重的是,某一个电路,用那一种形式的语言描述,才能将电路描述得更准确,综合以后产生的电路更合理。本文更偏重的是,编写 Verilog 代码时的书写习惯。 ) 二. 强调编写规范的宗旨。 缩小篇幅 提高整洁度 便于跟踪、分析、调试 增强可读性,帮助阅读者理解 便于整理文档 便于交流合作 三. 变量及信号命名规范。 1. 系统级信号的命名。 系统级信号指复位信号,置位信号,时钟信号等需要输送到各个模块的全局信号;系统信号以字符串 Sys 开头。2. 低电平有效的信号后一律加下划线和字母 n。如:SysRst_n;FifoFull_n; 3. 经过锁存器锁存后的信号,后加下划线和字母r,与锁存前的信号区别。如 CpuRamRd 信号,经锁存后应命名为 CpuRamRd_r。 低电平有效的信号经过锁存器锁存后,其命名应在_n后加 r。如 CpuRamRd_n 信号,经锁存后应命名为CpuRamRd_ 多级锁存的信号,可多加 r 以标明。如 CpuRamRd 信号,经两级触发器锁存后,应命名为 CpuRamRd_rr。 4. 模块的命名。 在系统设计阶段应该为每个模块进行命名。命名的方法是,将模块英文名称的各个单词首字母组合起来,形成3 到 5 个字符的缩写。若模块的英文名只有一个单词,可取该单词的前 3 个字母。各模块的命名以 3 个字母为宜。例如: Arithmatic Logical Unit 模块,命名为 ALU。 Data Memory Interface 模块,命名为 DMI。 Decoder 模块,命名为 DEC。 5. 模块之间的接口信号的命名。 所有变量命名分为两个部分,第一部分表明数据方向,其中数据发出方在前,数据接收方在后,第二部分为数据名称。两部分之间用下划线隔离开。 第一部分全部大写,第二部分所有具有明确意义的英文名全部拼写或缩写的第一个字母大写,其余部分小写。 举例:CPUMMU_WrReq,下划线左边是第一部分,代表数据方向是从 CPU 模块发向存储器管理单元模块(MMU) 。下划线右边 Wr 为 Write 的缩写,Req 是 Request 的缩写。两个缩写的第一个字母都大写,便于理解。整个变量连起来的意思就是 CPU 发送给 MMU 的写请求信号。 模块上下层次间信号的命名也遵循本规定。 若某个信号从一个模块传递到多个模块,其命名应视信号的主要路径而定。 6. 模块内部信号: 模块内部的信号由几个单词连接而成,缩写要求能基本表明本单词的含义; 单词除常用的缩写方法外(如:Clock-Clk, Write-Wr, Read-Rd 等) ,一律取该单词的前几个字母( 如:Frequency-Freq, Variable-Var 等) ; 每个缩写单词的第一个字母大写; 若遇两个大写字母相邻,中间添加一个下划线(如DivN_Cntr) ; 举例:SdramWrEn_n;FlashAddrLatchEn; 四. 编码格式规范。 1. 分节书写,各节之间加 1 到多行空格。如每个always,initial 语句都是一节。每节基本上完成一个特定的功能,即用于描述某几个信号的产生。在每节之前有几行注释对该节代码加以描述,至少列出本节中描述的信号的含义。 2. 行首不要使用空格来对齐,而是用 Tab 键,Tab键的宽度设为 4 个字符宽度。行尾不要有多余的空格。 3. 注释。 使用/进行的注释行以分号结束; 使用/* */进行的注释,/*和*/各占用一行,并且顶头; 例: / Edge detector used to synchronize the input signal; 4. 空格的使用: 不同变量,以及变量与符号、变量与括号之间都应当保留一个空格。 Verilog 关键字与其它任何字符串之间都应当保留一个空格。如: Always () 使用大括号和小括号时,前括号的后边和后括号的前边应当留有一个空格。 逻辑运算符、算术运算符、比较运算符等运算符的两侧各留一个空格,与变量分隔开来;单操作数运算符例外,直接位于操作数前,不使用空格。 使用/进行的注释,在/后应当有一个空格;注释行的末尾不要有多余的空格。 例: assign SramAddrBus = AddrBus31:24, AddrBus7:0 ; assign DivCntr3:0 = DivCntr3:0 + 4b0001; assign Result = Operand;5. 同一个层次的所有语句左端对齐;Initial、always 等语句块的 begin 关键词跟在本行的末尾,相应的 end 关键词与 Initial、always 对齐;这样做的好处是避免因 begin 独占一行而造成行数太多; 例: always ( posedge SysClk or negedge SysRst ) begin if( !SysRst ) DataOut else if( LdEn ) begin DataOut End else DataOut end 6. 不同层次之间的语句使用 Tab 键进行缩进,每加深一层缩进一个 Tab; 8. 在 endmodule,endtask,endcase 等标记一个代码块结束的关键词后面要加上一行注释说明这个代码块的名称; 9. 在 task 名称前加 tsk 以示标记。在 function 的名称前加 func 以示标记。例如: task tskResetSystem; endtask /of tskResetSystem 五小结: 以上列出的代码编写规范无法覆盖代码编写的方方面面,还有很多细节问题,需要在实际编写过程中加以考虑。并且有些规定也不是绝对的,需要灵活处理。并不是律条,但是在一个项目组内部、一个项目的进程中,应该有一套类似的代码编写规范来作为约束。 总的方向是,努力写整洁、可读性好的代码。 篇三:源代码管理规范代码管理制度 1 总则 .2 2 源代码完整性保障 .2 3 源代码的授权访问 .2 4 代码版本管理 .3 5 源代码复制和传播 .4 6 系统测试验收流程 .5 系统初验 .5 试运行 .5 系统终验 .5 系统验收标准 .6 文档评审通过标准 .7 确认测试通过标准 .7 系统试运行通过标准 . 7 1 总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的 SVN 库进行 SVNUpdate 操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行 SVNCommit 操作,在最终进行 SVNCommit 操作之前需要再进行 SVNUpdate 操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。 3 源代码的授权访问 1、源代码服务器对于共享的 SVN 库的访问建立操作系统级的,基于身份和口令的访问授权。 第十条 在 SVN 库中设置用户,并为不同用户分配不同的,适合工作的最小访问权限。要求连接 SVN 库时必须校验 SVN 中用户身份及其口令。在 SVN 库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用,或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定,必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。4 代码版本管理 1、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。 终端型号:终端型号是硬件标识号,也唯一的标识了我们的项目。 版本号:由(转载于: 小 龙文档 网:个体软件过程与编码规范)“主版本号.次版本号.修订号”三段组成,中间是点号分开。版本号的目的主要是管理终端软件的对外发布,终端软件的的记录和统计,主要是针对于版本号的,测试部、项目部、客户等会记录某个版本号的终端软件存在哪些,会在哪个版本号中得到修正;终端软件一个新的版本号出来后,我们会统计新的版本号解决了上一个版本号中的哪些,以及增加了哪些新功能,等等。 内部修订号:也就是“应用程序的源代码的 svn 修订号” ,主要是由软件部和测试部内部来使用,内部修订号唯一标识我们的终端软件,即:通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码,目的是为了软件排错使用。 另外,终端软件在发布时,还会给出发布日期,以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理 终端软件主要是以版本号为基准,对外发布,目前采用不定时发布策略,发布的时间由软件部、项目部和客户方根据情况,共同商量决定。 由于目前项目时间紧,终端软件无法得到完整的测试就要发布,在发布之后,有一些需要紧急需要修复的 BUG,软件部需要紧急修复后就要发布更新包,以便用户能够使用,所以,在一个版本号发布后,需要进行多次修订,对于这些修订的版本,其版本号保持不变,内部修订发生变化。 软件记录、管理和统计 软件的记录、管理和统计主要以版本号为基准,但为了软件开发人员能够找到的出处,需要用户、测试人员在报告和验证时,输入内部修订号。 3、软件配置组对版本的记录 软件版本记录的目标有两个: 记录软件版本的发布历史;发布的每一个版本,都要能够唯一的从源代码库()中找到对应的全部源代码。 测试方案:作为软件开发的重要环节,作为交付成功的优质的产品的重要保证手段和方法,软件测试越来越受到项目的重视。要做好测试首先要做好测试的组织、管理、计设、实施等工作。 系统测试方案概述:测试是指在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。 测试的目标:以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷,以确保系统的质量。 在实际项目中,测试作为软件开发生命周期中的一个重要过程,但从其具体工作的前后过程来看,它又是由一系列的不同测试所组成,这些测试的步骤分为:单元测试、集成测试(又称组装测试) 、确认测试和系统测试。软件开发的过程是自顶向下的,测试则正好相反,以上这些过程就是自底向上,逐步集成的。在项目过程中,我们按以上的测试步骤完成系统的测试。 5 源代码复制和传播 1、源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 2、源代码以任何介质形式进行存储的备份,必须由专人负责保管。对于这些介质地借阅,用于研发部内部使用的必须获得研发部经理的授权,对于用于研发部以外使用的必须获得总经理的书面授权。 3、源代码的借阅、复制必须进行详细的登记,必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 4、任何纸质材料的借阅都必需记录

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论