如何有效规范开发公司javaweb项目

2019独角兽企业重金招聘Python工程师标准>>>

1.为什么需要要规范管理
    a.web项目臃肿,不利于部署与管理,使用体验差
    b.项目中使用技术驳杂,可读性差
    c.项目业务不统一,往往开发出来的代码通用性差,扩展性差
    d.代码命名没有统一规范,注释少
    e.人员使用变动频繁,习惯性带入个人开发习惯,接手项目困难
    f.管理人员对代码审查薄弱
    
2.如何规范管理
    a.为了保证质量,降低成本,注重代码审查
    b.强制开发人员遵守项目开发代码命名等规范
    c.针对业务复杂的方法,做好注释
    e.坚决剔除一些扩展性差,不易维护的恶性代码

 

下面说是整理的一些关于代码规范的具体措施

一             目的

为了保证公司编写出的程序都符合相同的规范，而且便捷，保证一致性、统一性更符合构件化的要求而建立的程序编码规范，要使程序易懂。

二             范围

适用于企业所有基于JavaEE软件开发项目。

三             命名及开发规范

所有命名（类、函数、变量..）均要求意义明确易于理解，尽量使用有实际意义的英文单词或英文单词的缩写，避免在代码中直接使用数字等不确定意义的词，更切忌使用中文拼音的首字母。命名推荐使用驼峰命名方式

 

注释

外部注释

      外部注释指对文件、类、方法等添加注释头，可以利用Eclipse的注释模板功能快速的添加注释，注释模板设置方法,Eclipse->Windows->Preferences->Java->Code Style->Code Templates->Comments现统一规定如下：

      Files：

/**  

 *@Title:     ${file_name}

 *@Package        ${package_name}

 *@Description:   ${todo}

 *@author          finger

 *@date           ${date} ${time}

 *@version        V1.0  

 */

Types:

/**

 *@title            ${type_name}

 *@descript       ${todo}

 *@author         finger

 *@date              ${date}  ${time}

 *@version        V1.0

*/

Fields:

/**

 *@Fields         ${field} ${todo}

 */

 

Constructors:

/**

 *<p>Title:          </p>

 *<p>Description:    </p>

 *${tags}

 */

Methods:

/**

 *@title          ${enclosing_method}

 *@descript       ${todo}

 *@param          ${tags}

 *@return         ${return_type} 

 *@throws

 */

Overriding methods:

/*(non Javadoc)

 *<p>Title: ${enclosing_method}</p>

 *<p>Description: </p>

 *${tags}

 *${see_to_overridden}

 */

Delegate methods:

/**

 *${tags}

 *${see_to_target}

 */

Getters:

/**

 *@return the ${bare_field_name}

 */

Setters:

/**

 *@param ${param} the ${bare_field_name} to set

 */

外部注释需在必要的地方补充完整以下信息

@descript 描述成员方法的功能及存在的原因

@author 名称   后加上相应的作者

@version 文本  插入指定文本的版本信息

@param 参数-名称描述

@return返回值描述

@exception 完整的类名称 描述信息

@throws 完整的类名称 描述信息

@see 引用其他类，格式如下：@see 类名 

                           @see 完整类名

                           @see 完整类名#方法名

{@link引用}

           @Override   重载函数必须在函数头添加重载标示

内部注释

1. 在方法内部的开始部分统一注释方法的逻辑
2. 控制结构，结构性语句的起始位置需要注明，控制结构的尾部
3. 注明局部变量
4. 注释结束括号}
5. 注释要适当，使代码段落分明，一目了然。

JAVA规范

     Java代码

      Java源码中除静态常量定义外应禁止使用下划线(_)作为各种变量、函数、接口、类名等各种命名的字符，命名应尽可能不使用拼音及拼音缩写，而改用规范的英文翻译单词命名。其他具体命名规范如下：

Package

      Package的名字应为全部小写单词组成，不应包含大写字母、数字等其他字符，单词应为完整的单词或规范且公认的缩写。

例：com.companyName.mobile.app

Class

      Class的名字应为大写字母开头，后面单词也需大写字母开头。

例：TaskDetailActivity

Interface

      接口命名同Class

常量

      常量名字所有字符均须大写，单词间使用下划线(_)做分隔符。

例：CONNECT_TIMEOUT

变量

      变量的命名主要分以下两种方法：

Camel标志法：首字母是小写，接下来的单词都以大写字母开头。对于自定义的类或不常用的类对象使用该种命名法则(除下述外的类型)。

书写规范

      代码的书写规范主要从注释和书写习惯对代码进行一个规范。一段规范的代码不仅便于调试及时发现错误所在，更能给他人或者日后自己维护带来许多便利，需要注意以下几点：

1.     注释文档

2.     段落化

3.     多行语句段落化

4.     使用空格和空行

5.     方法不能太长，遵循30秒规则

6.     定义消息的传递，在注释中体现

7.     简短的命令行

8.     将比较的常数放在左方，以防止误写为赋值语句

书写习惯

缩进

      缩进一般参照Eclipse默认Format的缩进，Eclipse使用Ctrl+Shift+F快捷键来快速格式化当前文件代码，默认缩进为1个Tab即4个空格的字符长度。语句块的{}，其中{要跟在分块开始语句之后，如：函数定义、if条件和循环语句等末尾，else语句不单独另起一行。

例：

if (“abcd”.equals()){

……

}else{

……

}

空格

      原则上变量、类、常量数据和函数在其类型，修饰名称之间适当空格并据情况对齐。关键字原则上空一格，如：if ( ... ) 等。运算符的空格规定如下："::"、"->"、"["、"]"、" "、"--"、"~"、"!"、" "、"-"（指正负号）、"&"（引用）等几个运算符两边不加空格（其中单目运算符系指与操作数相连的一边），其它运算符（包括大多数二目运算符和三目运算符"?:"两边均加一空格，在作函数定义时还可据情况多空或不空格来对齐，但在函数实现时可以不用。","运算符只在其后空一格，需对齐时也可不空或多空格。不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。

对齐

      原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在","处或运算符处，换行后最好以运算符打头，并且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下一行为“{”应与首行对齐。变量定义最好通过添加空格形成对齐，同一类型的变量最好放在一起。如下例所示：
int Value;

int Result;

int Length;

Object currentEntry;

空行

      不得存在无规则的空行，比如说连续十个空行。程序文件结构各部分之间空两行，若不必要也可只空一行，各函数实现之间一般空两行，由于每个函数还要有函数说明注释，故通常只需空一行或不空，但对于没有函数说明的情况至少应再空一行。

代码长度

      对于每一个函数建议尽可能控制其代码长度为53行左右，超过53行的代码要重新考虑将其拆分为两个或两个以上的函数。函数拆分规则应该一不破坏原有算法为基础，同时拆分出来的部分应该是可以重复利用的。对于在多个模块或者窗体中都要用到的重复性代码，完全可以将起独立成为一个具备公用性质的函数，放置于一个公用模块中。

页宽

      页宽应该设置为80字符。源代码一般不会超过这个宽度, 并导致无法完整显示, 但这一设置也可以灵活调整. 在任何情况下, 超长的语句应该在一个逗号或者一个操作符后折行. 一条语句折行后, 应该比原来的语句再缩进2个字符。

变量初始化

      对变量最好始终进行定义初始化，以减小不容易调试的bug的产生。

去除警告

      对文件中的警告，应尽量或极力去消除警告，对于暂时长时不使用的函数，可以使用添加@SuppressWarnings("unused")来去除警告或在配置库(VSS、CVS、SVN)保存有备份的情况下暂时删除该方法。

其他

      对于比较应把常量放在前面，以免误写为赋值语句或者造成不必要的空指针错误。

例：

while (0 == flag){

……

}



if (“abcd”.equals(sName)){

……

}

减少不必要的语句和局部变量定义或冗余的写法

例：

冗余的写法：

boolean bResult = false；

if ( a == b){

      bResult = true;

}else{

      bResult = false;

}

return bResult;

正确的写法：

return a == b;

冗余的写法：

if (bIsFile == fasle) {

      ……

}

正确的写法：

if (! bIsFile) {

      ……

}

 

常用规范编码规范

1.     使用 get/set 对类属性进行访问，这是Java 社区的核心编码规范。

2.   使用 is 前缀表示一个布尔变量和方法。

a)  isUsed, isEmpty,isVisible,isFinished

                         i.      有时也可以使用 has，can，should：

1.  boolean hasLicense();

2.  boolean canEvaluate();

3.  boolean shouldAbort = false;

3.   在查询方法中应使用 find 作为前缀

vertex.findNearestVertex();

matrix.findSmallestElement();

4.  使用 initialize 做为对象初始化的方法前缀，也可以简写为init

initializeFiles();

init();

initFontSet();

5.   对于对象集合， 变量名称应使用复数。

Collection<Point> points;

int[] values;

6.   对于抽象类，应该使用 Abstract 前缀。

                         i.      AbstractReportBuilder，AbstractBeanFactory

7.   对于表示编号的变量，应加 No 后缀。

a)  tableNo, userNo,employeeNo

8.   常在一起使用的对称词汇，这些词汇一起使用，方法的表达意图自然可以互相推测和演绎。

get/set, add/remove, create/destroy, start/stop,

insert/delete, increment/decrement, begin/end, first/last,up/down, min/max, next/previous, old/new, open/close,show/hide, suspend/resume

9.   避免使用否定布尔变量

a)  bool isError; // 避免: isNoError

b)  bool isFound; // 避免: isNotFound

10. 异常类应该使用 Exception 做为后缀。

a)  AccessException, RuntimeException

缺省接口实现应该使用 Default 前缀

class DefaultTableCellRenderer

implements TableCellRenderer {

…

}

11. 对于单例类（Singleton），应该使用getInstance 方法得到单例。            

public class UnitManager {

private final static UnitManager instance new UnitManager();

private UnitManager() {

...

}

public static UnitManager getInstance(){

return instance_;

}

}

12. 对于工厂类，进行创建对象的方法，应该使用 new 前缀

 class PointFactory {

public Point newPoint(...)

...

}

}

 

转载于:https://my.oschina.net/java1314/blog/796024