项目开发及编码规范
- 格式:doc
- 大小:88.00 KB
- 文档页数:17
软件测试中的编码规范与质量标准在软件开发过程中,编码规范和质量标准是确保软件质量的重要因素。
编码规范是一组约定俗成的规则,用于指导开发人员编写可读性强、可维护性好的代码。
而质量标准则是用于评估软件的质量水平,以确保软件能够满足用户需求并具备高可靠性和稳定性。
首先,编码规范在软件测试中起到了至关重要的作用。
一个良好的编码规范可以提高代码的可读性和可维护性,从而减少软件缺陷的产生。
例如,规定变量和函数的命名规范、缩进和注释的使用规范等,可以使代码更易于理解和修改。
此外,编码规范还可以规范代码的结构和风格,使得团队成员之间的协作更加高效。
例如,规定代码的缩进方式、代码块的排列方式等,可以提高代码的一致性,减少不必要的冲突和错误。
其次,质量标准是评估软件质量的重要依据。
软件测试旨在发现和修复软件中的缺陷,以确保软件的正常运行和满足用户需求。
而质量标准则是用于评估软件测试的效果和软件的质量水平。
例如,测试覆盖率是一个常用的质量标准,用于衡量测试用例对软件代码的覆盖程度。
高测试覆盖率意味着测试用例更全面,能够发现更多的缺陷。
此外,质量标准还可以包括性能、可靠性、安全性等方面的指标,以确保软件具备良好的用户体验和稳定性。
在软件测试中,编码规范和质量标准是相互关联的。
良好的编码规范可以提高代码的质量,从而提高软件测试的效果。
而质量标准则可以对软件的质量进行评估,以指导开发人员遵循编码规范和改进软件测试的方法和策略。
因此,在软件测试中,开发团队应该制定并遵守一套合理的编码规范,并根据质量标准进行测试和评估。
然而,编码规范和质量标准并非一成不变的。
随着软件开发技术的不断发展和变化,编码规范和质量标准也需要不断更新和改进。
例如,随着敏捷开发和DevOps的兴起,软件开发过程变得更加快速和迭代。
因此,编码规范和质量标准也需要适应这种变化,并提供更加灵活和可持续的解决方案。
此外,不同的软件项目和领域也可能有不同的编码规范和质量标准。
项目规范保障措施在项目开发过程中,规范的操作流程和良好的开发习惯可以提高开发效率和代码质量。
本文将介绍一些项目规范保障措施,包括编码规范、版本控制、代码审查、单元测试等。
编码规范编码规范是保证代码质量的基石,在开发项目时应该遵循合适的编码规范。
以下是一些编码规范的建议: - 命名规范:命名应该明确、有意义,不使用缩写和拼音,并且统一规范。
- 缩进规范:应该使用统一的制表符或空格进行缩进,不应该混用。
- 注释规范:代码应该加入必要的注释,尤其是业务逻辑等复杂代码部分。
- 错误处理规范:应该在代码中处理所有预期和异常情况,避免可能导致程序崩溃的错误。
版本控制版本控制是代码开发过程中必须的一项工作,可以让多人同时开发同一份代码,并且可以方便地跟踪代码改动和恢复历史版本。
以下是一些版本控制的原则: - 使用合适的版本控制工具,如Git、SVN等。
- 对代码库进行适当的分支管理,例如主干、开发分支和发布分支等。
- 在代码库中进行合理的注释和文档记录,方便后续维护和开发。
代码审查代码审查是项目开发中重要的一项环节,可以保证代码风格的一致性和代码质量的稳定性。
以下是一些代码审查的原则: - 定期进行代码审查,一周或一个月进行一次。
- 设置合适的代码审查标准和规则,提高开发团队的代码质量和审查能力。
- 将代码审查的结果记录在一份文档中,方便做出改善和总结。
单元测试单元测试是保障代码质量的另一重要环节,可以在代码开发过程中及时发现代码缺陷和错误。
以下是一些单元测试的原则: - 设计合理的单元测试用例,覆盖核心逻辑和边界情况。
- 使用合适的单元测试工具,如JUnit、PyTest、RSpec等。
-对单元测试结果进行统计和分析,及时发现和解决问题。
总结在项目开发过程中,规范的操作流程和良好的开发习惯可以提高开发效率和代码质量。
编码规范、版本控制、代码审查和单元测试都是非常重要的保障措施,需要在项目开发过程中得到充分的重视和运用。
编码规范为何重要以及如何实践在软件开发过程中,编码规范是一项非常重要的指导性文件。
它定义了编程人员在编写代码时应该遵循的规范和标准,包括命名约定、代码布局、注释规范等。
编码规范的重要性体现在以下几个方面。
首先,编码规范有助于提高代码的可读性和可维护性。
一个良好的编码规范能够使代码结构清晰、逻辑明确,使开发人员能够更容易地理解和维护代码。
统一的命名约定和代码布局规范也能够减少代码阅读和理解的时间,提高开发效率。
其次,编码规范有助于提高代码的质量和可靠性。
严格遵循编码规范能够帮助开发人员在编码过程中发现和纠正潜在的错误和缺陷。
规范的注释和文档要求也有助于完善代码的文档资料,方便其他开发人员理解和使用代码。
另外,编码规范有助于促进团队合作。
在一个团队协作开发的项目中,统一的编码规范能够使多人协同工作更加高效。
开发人员之间可以更容易地理解和调试彼此的代码,减少沟通成本。
同时,统一的编码规范也有助于保持团队的代码风格一致,提升项目的整体品质。
那么,如何来实践编码规范呢?以下是一些实践编码规范的建议。
首先,制定一份明确的编码规范文档。
编码规范应该包括命名规范、代码布局规范、注释规范、异常处理规范等内容。
这份文档应该被整个团队共享和遵循,并在项目初期进行培训和讨论,确保团队成员都了解和遵守规范。
其次,利用工具来辅助实践编码规范。
有些代码编辑器和集成开发环境提供了代码检查和格式化工具,可以自动检查和修正代码规范问题。
团队可以根据自己所使用的开发工具,选择合适的插件或配置来进行规范检查,减少人为错误。
另外,进行代码审查和知识分享。
团队成员可以相互检查彼此的代码,发现潜在的违规问题,并提供改进意见。
同时,团队可以定期举行代码分享会议,分享一些编码规范的最佳实践和经验,共同提高团队的编码水平。
此外,持续学习和更新编码规范。
编码规范并非一成不变的,随着技术和项目需求的演变,规范也需要不断更新和调整。
团队应该时刻关注最新的编码规范和行业的最佳实践,及时更新自己的规范文档和实践。
最新项目管理编码规则引言本文档旨在统一最新的项目管理编码规则,以便项目团队的成员能够在项目实施过程中有效地进行编码,提高项目的效率和质量。
本规则适用于所有项目管理阶段,包括需求分析、设计、开发和测试等环节。
规则列表1. 代码命名规范- 采用英文字符和数字组成的有意义的名称,禁止使用拼音、无意义的单词或者数字组合作为代码的命名;例如:`addNewUser`。
- 使用驼峰命名法,即首字母小写,后续单词首字母大写;例如:`getUserInfo`。
- 避免使用过长的命名,推荐保持简洁和易读性。
2. 注释规范- 在代码中添加必要的注释,解释代码的功能、目的和关键步骤等信息。
- 使用中文注释,避免使用过于简单或者晦涩难懂的注释。
- 注意及时更新注释,保持与代码的一致性,避免注释与代码不符导致混淆。
3. 代码缩进和格式化规范- 使用统一的代码缩进,推荐使用四个空格作为缩进。
- 统一的代码格式化规范,包括对齐、空格、换行等。
- 遵循一致性原则,统一代码风格,减少团队成员之间的代码差异。
4. 错误处理规范- 优先处理常见错误,确保代码的鲁棒性和稳定性。
- 使用异常处理机制来处理错误,避免使用简单的错误码返回。
- 在出现错误时,记录错误信息,并进行合理的提示或者处理。
5. 代码复用规范- 鼓励代码复用,避免重复造轮子。
- 可以封装通用代码为函数或类,提高代码的可复用性。
- 注意复用代码的适用性和正确性,避免不必要的复用。
6. 版本控制规范- 使用版本控制工具,如Git等,管理代码的版本。
- 使用合适的分支管理策略,确保项目的代码可以有序地进行开发和维护。
总结以上为最新的项目管理编码规则,通过遵守这些规则,项目团队的成员可以更好地进行编码工作,提高项目的质量和效率。
同时,也能够减少团队成员之间的代码差异,便于代码的维护和协作。
请全体成员严格遵守本规范,如有任何疑问或建议,请及时反馈给项目管理人员进行沟通和修改。
参考文献无。
开发规范总结报告范文一、引言开发规范是软件开发过程中非常重要的一部分,它可以确保团队成员具有一致的编码风格、规范的命名习惯以及高质量的代码。
因此,制定和遵循开发规范对于提高开发效率、减少错误和提升代码可读性具有重要意义。
本报告旨在总结我们团队在开发规范方面的经验和教训,为今后的项目开发提供参考。
二、编码风格规范编码风格规范是保证项目中代码一致性的关键。
我们团队制定了以下几个编码风格规范:1. 缩进和空格:统一使用4个空格进行缩进,不要使用制表符。
2. 命名规范:变量和函数名使用小驼峰命名法,类名使用大驼峰命名法。
命名要具有描述性,避免使用缩写和简写。
3. 代码格式:遵循一致的代码格式,包括大括号的位置、代码的对齐等。
同时,在代码块之间使用空行进行分隔,提高可读性。
4. 注释规范:对于函数和重要逻辑,添加必要的注释,以便其他开发人员理解和维护代码。
注释应该清晰、简明,并使用英文书写。
三、命名规范良好的命名规范是代码可读性和可维护性的关键。
以下是我们团队遵循的命名规范:1. 变量和函数名:使用有意义的名称来描述变量和函数的用途,避免使用单个字符或无意义的命名。
2. 类名:类名使用大驼峰命名法,应具有描述性。
3. 常量名:常量全大写,单词间用下划线分隔。
4. 文件名:文件名应该与文件包含的内容相关联,使用小写字母和连字符分隔单词。
四、异常处理规范良好的异常处理机制可以提高程序的健壮性和可靠性。
以下是我们团队制定的异常处理规范:1. 捕获异常:应该在可能发生异常的地方进行捕获,并给出合适的处理逻辑。
2. 异常类型:选择适当的异常类型来捕获和处理异常,避免使用通用的Exception类。
3. 异常日志:在捕获异常时,应该记录异常的详细信息以便后续排查和修复。
五、注释规范良好的注释可以提高代码的可读性和可维护性。
以下是我们团队遵循的注释规范:1. 类注释:每个类应该包含类的描述、作者、创建日期等信息。
2. 方法注释:每个方法应该包含方法的描述、输入参数、输出结果和异常情况等信息。
编码规范引发的问题与解决方案编码规范是在软件开发过程中,规范团队成员在编写代码时应遵循的一组准则。
良好的编码规范可以提高代码的可读性、可维护性和可重用性,同时还可以减少错误和提高团队的工作效率。
然而,编码规范本身也会引发一些问题,本文将讨论这些问题,并提供解决方案。
一、缺乏统一的编码规范会导致代码质量下降和协作困难。
解决方案:制定一份统一的编码规范,并确保所有团队成员都遵守。
编码规范应当包括对命名规范、代码风格、注释规范、错误处理规范等的详细规定。
同时,还需要借助代码审查工具来检查代码是否符合规范,以及将规范列入团队评估和绩效考核中,以强调其重要性。
二、编码规范过于死板,不能适应不同的项目需求。
解决方案:编码规范应该是可定制的,以适应不同项目的需求。
可以制定一些基本的规范,如命名规范和代码风格,然后根据项目的具体需求,灵活调整其他规范。
此外,对于一些特定的技术要求或开发工具,可以制定专门的规范。
三、团队成员对编码规范的知识和理解程度不一致。
解决方案:应该对团队成员进行编码规范的培训和教育,确保每个人都理解并能够正确地应用规范。
可以组织一些培训课程、工作坊或内部讲座,介绍编码规范的重要性、原则和实际应用。
同时,还可以在编码规范的文档中提供示例和解释,帮助团队成员更好地理解。
四、编码规范更新困难,导致跟不上技术和行业的发展。
解决方案:定期审核和更新编码规范,以使其与最新的技术和行业标准保持一致。
可以建立一个专门的编码规范委员会,由团队中的高级开发人员和架构师组成,负责收集和分析最新的技术趋势和行业发展。
根据他们的建议和意见,对编码规范进行更新,并向团队成员进行通知和培训。
五、编码规范不合理或过于严格,影响团队成员的创造力和工作效率。
解决方案:编码规范应该是合理和具体的,既能提高代码质量,又能给团队成员留出一定的创造空间。
应该鼓励团队成员提出意见和建议,以使编码规范更加灵活和可接受。
此外,还可以通过定期的反馈和评估,对编码规范进行调整和优化,以提高团队的工作效率。
软件开发公司代码编写规范软件开发公司的代码编写规范是为了确保开发出高质量、可维护、可扩展的软件。
本文将介绍一些常见的代码编写规范,旨在提高团队协作效率和代码质量,并促进项目的成功开发。
1. 命名规范- 使用有意义、清晰简洁的变量、函数和类名称。
- 遵循驼峰命名法,首字母小写。
- 类名应以大写字母开头。
- 避免使用缩写和简写,尽量使用具有描述性的名称。
2. 注释规范- 对代码进行详细注释,解释代码的功能、目的和实现方式。
- 注释应放在代码行上方,使用自然语言、规范的语法。
- 避免过多无用的注释,注释应精准、简洁明了。
3. 编码规范- 使用一致的缩进和空格,增强代码的可读性。
- 适当添加空行将代码分块,提高代码的可读性。
- 代码行长度控制在80个字符以内,避免过长的代码行。
- 使用简洁明了的语句和表达式,避免过度复杂的代码逻辑。
4. 错误处理规范- 使用异常处理机制处理可能出现的异常情况。
- 避免使用裸露的try-catch语句块,应具体指明捕获的异常类型。
- 在异常处理中提供清晰的错误提示信息。
5. 面向对象规范- 使用设计模式和面向对象的原则,提高代码的可维护性和扩展性。
- 单一职责原则:每个类应该只有一个明确的责任。
- 开放封闭原则:对扩展开放,对修改封闭。
6. 文档规范- 编写清晰的文档,介绍项目的整体结构、功能和使用方法。
- 说明代码中特殊函数、算法或者复杂业务逻辑的实现方式。
- 提供示例代码和演示,帮助他人更好地理解和使用代码。
7. 版本控制规范- 使用版本控制工具(如Git)进行代码管理,并遵守团队约定的分支规范。
- 提交代码前进行代码审查,确保代码质量和规范。
- 使用有意义的提交信息,描述代码变更内容。
8. 测试规范- 使用单元测试框架编写单元测试用例,覆盖核心逻辑。
- 遵循测试驱动开发(TDD)原则,在编写代码前先编写测试用例。
- 运行自动化测试,确保代码变更不会破坏系统稳定性。
总结:软件开发公司的代码编写规范是确保团队成员以相同的标准进行代码编写,提高代码质量和可维护性的重要规范。
开发规范文档开发规范文档一、概述开发规范文档旨在规范开发团队的编码和开发标准,提高代码质量,降低维护成本,保证项目的稳定性和可扩展性。
本文档适用于所有的开发人员和项目。
二、命名规范1. 类名、接口名、枚举名使用大驼峰命名法,首字母大写,后续每个单词首字母大写,例如:UserService、CalculatorService;2. 变量名、方法名使用小驼峰命名法,首字母小写,后续每个单词首字母大写,例如:userName、calculateSum;3. 常量名全部大写,多个单词之间用下划线分隔,例如:MAX_LENGTH;4. 包名使用小写字母,并且能够反映该包的功能,例如:com.example.service;5. 数据库表名使用小写字母,并且采用下划线分隔,例如:user_info;6. 文件名使用小写字母,并且能够描述该文件的内容,例如:user_service.java。
三、代码规范1. 缩进和对齐:使用4个空格进行缩进,不使用Tab键;在定义变量和方法时,尽量对齐;2. 行长限制:每行不超过100个字符;3. 注释规范:每个类、方法、成员变量必须添加注释说明,方便他人理解;4. 异常处理:在捕获异常时,要进行适当的处理,避免出现空指针异常等运行时错误;5. 空行规范:在函数、类之间使用空行分隔,提高代码的可读性;6. 文件编码:使用UTF-8编码,禁止使用乱码字符;7. 导入包规范:按照层级结构进行导入,不使用通配符*;8. 常量和变量声明:常量建议使用final修饰,变量声明后要及时初始化;9. 错误处理:在遇到错误时,要及时打印日志记录,方便定位和解决问题;10. 重写方法:重写Object类的方法时,要加上@Override注解,增强代码的可读性。
四、注释规范1. 类注释:在每个类的前面添加注释,描述该类的作用和功能;2. 方法注释:在每个方法的前面添加注释,描述方法的输入参数、返回值和功能;3. 成员变量注释:在每个成员变量的前面添加注释,描述变量的作用和用途;4. 异常注释:在方法上方的注释中,说明该方法可能抛出的异常类型和原因。
项目编码规范文件状态:[]草稿[]正式发布[√]正在修改文件标识:项目编码规范当前版本: 1.0作者:张波完成日期:2010-8-20参考文件:NoticeDAL.cs 文件及文档注释,类,方法,变量命名NoticeModel.cs 属性定义,私有变量MainPage.xaml xaml中相关注释,控件命名MainPage.xaml.cs 其他规范编码规范目的当团队的所有开发人员都在同一个代码上工作时,也就是代码集体拥有的情况,大家都不希望别人改变代码的外观以适应他们自己的风格。
因此,通过在项目之初达成一个编码标准,就可以增加团队的生产率和沟通效果。
1.基本规则有两种主要类型的字母大小写形式:Pascal和camel。
对于Pascal字母大小写形式来说,所创建名称的第一个单词的第一个字母是大写的,该名称中的后续单词也是如此,例如ThisIsPascalCase。
对于camel字母大小写形式来说,所创建名称的第一个单词的第一个字母是小写的,而该名称中的后续单词使用大写的字母,例如thisIsCamelCase。
2.如果可以更清楚地描述事物的含义,大家应该尽量使用完整的单词,而不是缩略语。
让其他人在看到我们的变量方法名时,大概能猜出它是做什么的。
2.命名规范项大小写形式相关例子注释Pascal命名规则文件Pascal DatabaseConnector使用名词来描述类Pascal Public class DatabaseConnector{}类的名称应该与定义它们的文件的名称匹配接口Pascal interface IdatabaseConnector{} 接口名称以字母I开头方法Pascal CalculateBalance()使用动词来描述方法单元测试方法Pascal TestFindAllCustomers()单元测试名称以单词Test开头。
属性Pascal public string AccountNumber{get{return accountNumber;}}公共实体字段Pascal CustomerName公共类字段Pascal public static bool HasGoodCredit = true 命名空间Pascal namespace DataLayer解决方案Pascal NorthWindTrader项目Pascal DataLayer委托Pascal public delegate void MouseEventHandler(object sender, MouseEventArgs e); 在命名的后面加EventHandlerCamel命名规则私有的实例字段camel private float_accountBalance以_开头,第一个字母小写私有和受保护的类字段camel protected static int numberOfAccounts局部变量camel string accountNumber=FindAccountByCustomerName(customerName)过程的参数变量camel public class hello{void say(string p_sayWord){}}过程的参数使用“p_”作为前缀.参数camel public voidGetCurrentBalance(string accountNumber)常量全部大写Decimal MINNUM_BALANCE=100全部大写,单词之间以“_”分隔控件对象命名规则TextBox控件:前缀为txtTextBlock控件:Label控件:前缀为lblButton控件:前缀为btnComboBox控件:前缀为cmbCheckBox控件:前缀为chkRadioButton控件:前缀为radPanel控件:前缀为pnlDataGrid控件:前缀为grdBorder控件:前缀为brdTreeView控件:前缀为treContextMenu控件:前缀为cmu数据库命名规则视图:v_<ViewName>首字母大写存储过程:sp_<SpName>首字母大写触发器:t _<TriggerName> 首字母大写函数过程:fn_<FunctionName>首字母大写列名表名:一般第一列名为ID、主键、标识递增,其他列名表名推荐采用Pascal命名方式,尽可能用英文单词或英文缩写,如英文过长(超过6位)或过于生僻可用汉语拼音的首字母。
项目开发规范文档 修订历史记录 日 期 版 本 说 明 作 者 2009-12-25 初稿 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) 成员方法尽量私有化。 d) 方法与方法之间空一行分割,提高可读性。 c) 方法尽可能有注释:(详细查看:注释) e) 方法尽可能尽早返回,结束。
3.1.3 Java语句 3.1.3.1 缩进排版 a) 4个空格(一个Tab建)常被作为缩进排版的一个单位。子模块应该和父模块保持一个缩进单位。 b) 尽量避免一行的长度超过80个字符. c) 换行: 当一个表达式无法容纳在一行内时,可以依据如下一般规则断开之: - 在一个逗号后面断开 - 在一个操作符前面断开 - 宁可选择较高级别(higher-level)的断开,而非较低级别(lower-level)的断开 - 新的一行应该与上一行同一级别表达式的开头处对齐 - 如果以上规则导致你的代码混乱或者使你的代码都堆挤在右边,那就代之以缩进8个空格。 如: someMethod(longExpression1, longExpression2, longExpression3, longExpression4, longExpression5);
var = someMethod1(longExpression1, someMethod2(longExpression2, longExpression3));
3.1.3.2 注释 Java程序有两类注释:实现注释(implementation comments)和文档注释(document comments)。实现注释是使用/*...*/和.*/界定。文档注释可以通过javadoc工具转换成HTML文件。 实现注释用以描述实现的细节,流程,和难点的描述。良好的实现注释有助于自己和别人易于读懂代码。文档注释它可以被那些手头没有源码的开发人员了解接口功能等。 频繁的注释有时反映出代码的低质量。当你觉得被迫要加注释的时候,考虑一下是否可以重新设计该模块的代码结构或者逻辑,使其更清晰,而避免使用注释提醒该模块的实现,这样往往都能够提高代码质量。 注释应被用来给出代码的总括,良好的代码里应该有大量的注释。当然也要避免代码已经提供清晰明了,显而易见注释。
注释的格式: 程序可以有4种实现注释的风格:块 、单行 、尾端 和行末 。 分别由: /** notice */ 块 /* notice */ 单行 /* notice */ 尾端 Ltd. All right reserved. 过程和方法注释与JavaDoc中对应: 功能描述: Method Comments 参数说明: Parameter Comments 返回值说明: Returns 最后更新作者: 如有改动,自己添加 最后更新日期: 如有改动,自己添加
/** * 对系统规范化的异常处理。包含各种异常编码,标准出错提示与日志的产生和管理。 * * 异常类型ID * 1-49 :系统内部异常 - 标准处理:写日志,向客户端抛出CustomException异常 * 50-99 :用户界面异常 - 标准处理:写日志,向客户端抛出对应的自定义异常 * 100以上:扩展异常 * * 注意:写日志时应使用 getSysMsg() 获得对应的异常日志记录串;向用户端抛出的 * 异常则在 getUserMsg() 中携带应在界面上显示的信息串
2006-5-15. ... //modify by XXX2006-5-15 end
/** * 初始化方法,在这里初始化所有用户公用的变量, * 这里简单地将工作交给父类处理。 * @param config ServletConfig对象,包含Servlet初始化的参数。 * @throws ServletException 初始化可能产生ServletException异常。 3.1.3.3 语句示例: a) 简单语句 每行至多包含一条语句,例如: argv++; . } 注意:空格不应该置于方法名与其左括号之间。这将有助于区分关键字和方法调用。 - 空白应该位于参数列表中逗号的后面 - 所有的二元运算符,除了".",应该使用空格将之与操作数分开。一元操作符和操作数之间不因该加空格,比如:负号("-")、自增("++")和自减("--")。例如: a += c + d; a = (a + b) / (c * d);
while (d++ = s++) { n++; } printSize("size is " + foo + "\n");
- for语句中的表达式应该被空格分开,例如: for (expr1; expr2; expr3)
- 强制转型后应该跟一个空格,例如: myMethod((byte) aNum, (Object) x); myMethod((int) (cp + 5), ((int) (i + 3)) + 1);
Jsp, JavaScript 代码规范 3.2.1 Jsp文件 Jsp文件命名,首字母要求小写,名称可以用多个单词组成。每个单词组合时候首字母大写。 建议: 列表页面为: 表单展示页面为: 表单修改页面为:
Jsp文件的内容编码格式 和 文件本身的编码格式要求统一。具体视项目要求。 页面尽量使用同一种标签表达,比如只使用struts标签, 或者JSTL标签。
3.2.2 JavaScript文件 JavaScript脚本尽量建立独立的以”js” 为后缀的独立文本文件。页面单独应用js文件即可。文件命名与jsp文件相同。文件本身的编码格式需要和整个项目文件编码一致。 一个js文件包含一个或者多个function函数。
数据库对象定义规范 3.3.1 表名命名规则
数据库表的命名以是名词的复数形式且都为大写,如ACCOUNT,INDICATOR_HISTORY等等 如果表名由几个单词组成,则单词间用下划线("_")分割,如 CURRENT_COUNTER等 表名尽量用全名 表名限制在30个字符内。当表的全名超过30字符时,可用缩写来减少表名的长度,如description --> desc;information --> info;address --> addr等 (oracle限制表名超过30个字符)
3.3.2 表字段名命名规则
字段名为小写 字段名为有意义的单词,或单词的缩写 如果字段由几个单词组成,则单词间用下划线("_")分割,如client_id,post_code等 字段名限制在30个字符内。当字段名超过30字符时,可用缩写来减少字段名的长度,如description --> desc;information --> info;address --> addr等
3.3.3 索引命名规则
索引须按照IDX_table__,其中是建立索引的表名,是建立索引的字段名 索引名限制在30个字符内。当索引名超过30字符时,可用缩写来减少索引名的长度,如description --> desc;information --> info;address --> addr等
3.3.4主建、外键命名规则
主键按照PK_