jsp文件命名规范_代码规范整理

我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省的引诱别人做没规矩的优化，高出一对混乱来。整洁的代码只做好一件事情。”

—Bjarne Stroustrap C++语言发明者

概述

编写该文档的目的在于为团队成员中代码的编写和重构工作提供指引，从而提高代码的质量。该文档主要从以下角度去梳理规范的具体内容：

提高代码的运行效率；
提高代码的整洁性；
提高代码的可读性；
提高代码的可

页面编写要求

在编写JSP页面时，开发人员通常会把css、js放在<head></head>之间，这种做法很常见、也能让页面正常显示。但是将页面中css、js放置的位置稍作调整，页面渲染的速度就会有翻倍的提升，因此我们建议jsp页面中的css、js按如下规则调整：

将样式表（包括css文件和内联的css）放在<head></head>之间；将js脚本（包括引用的js文件和内联的js函数）放在底部（</body>之后）。示例如下：

<html><head><link type=”text/css” rel=”stylesheet” herf=”” /></head><body><div></div></body><script type=”text/javascript” src=””></script><script type=”text/javascript”></script></html>

将事务操作放在Service层

通常我们的代码框架中对事务的操作是放在service层实现。有些同事没注意到这个细节，会将对数据的操作代码写在action层，这样的代码将脱离事务的控制，在系统运行出现异常时，不能保证数据的一致性。对此，我们建议与事务相关的代码其位置跟框架保持一致，放在service层实现。

删除废弃代码

在项目开发的过程中，可能会因为需求变更、复制粘贴等原因而出现一些废弃代码，在系统运行过程中，这些代码可能不被执行、可能执行的操作与系统无关，甚至执行该段代码耗费的时间拖慢系统运行的速度。为了提高代码的整洁和可读性，对于这类代码，我们建议删除。

去除警告信息

在阅读代码的时候，有时会发现在一些java类和jsp文件中存在黄色感叹号或者黄色波浪线，他们的出现意味着代码中存在无关的类引用或者使用了过时的方法。

这些带警告性质的提示信息不会影响系统的运行，但是相信大部分开发人员都有一定程度的洁癖，我们建议尽量去除这些警告信息。

合并重复代码

项目开发过程中，“复制粘贴”已成为了一种必不可少的开发手段。开发人员在开发类似或者相同业务功能时，通常做法也是拷贝代码，这样省时省力。要是这类代码一处出现BUG，开发人员不得不去修改多处代码，这样无疑大大增加了维护的工作量和出现BUG的风险。

对此，我们不妨将这重复类似的逻辑代码抽离出来，合并封装成一个方法。理想情况下，该方法应简明扼要。若边幅太长，可考虑通过某种方式将其分成较短的几个方法，这样也便于代码的重复使用。

原则上，类之间都可以使用的逻辑，我们将它封装成公用方法，若只是类内使用，则封装成私有方法。

使用 Idea 时一个工作区如果代码块重复会有重复提示的。

使用公用的方法

开发人员在花一定时间实现某个功能后，发现其他同事也写过类似的功能。这种情况不少见。重复发明轮子的弊端这里不做累述，我们建议大家多使用公用的方法。

下面的代码库我们可能会经常用到：common-utils中的方法等系列等。java 提供了很多的封装的工具包，要善于利用，因为工具包往往都经过很多人验证过的。

有意义的命名

软件中随处可见命名。我们给变量、函数、参数、类和包命名；我们给源代码所在目录命名；我们给jar文件、war文件、ear文件命名。我们命名、命名、不断命名，既然有这么多命名做，不妨做好它。

下面列出了取个好名字的几条简单规则：

名副其实变量、函数或类的名称能够清晰地表达它为什么存在，它做什么事情，应该怎么用。如果名称需要注释来补充，那该命名就不算名副其实。
避免误导以下两个方面可以借鉴：提防使用不同之处较小的名称，比如区分下面两个变量名ControllerForEffiHandingOfStrings和ControllerForEffiStorageOfStrings需要特别的细心，这种情况就是需要避免的；注意两对误导性很强的组合：小写字母l和数字1、大写字母O和数字0。
做有意义的区分

避免依据数字系列命名以数字系列命名是依义命名的对立面，完全没有提供正确信息，没有提供导向作者意图的线索。下面是一个具体的例子：

以数字系列命名
public static void copyChars(char[] a1,char[] a2){}有意义的区分
public static void copyChars(char[] source,char[] target){}

废话是一种没意义的区分假设你已经有类 Product，如果还有类 ProductInfo 或者 ProductData，那他们的名称虽然不同，意义却无区别。如果API中提供如下方法：

getActiveAccount();getActiveAccountInfo();

试问仅通过方法名，程序员怎么知道调用哪个方法。

类名和方法名的命名

类名和对象名可以是名词或名词短语。方法名应可以是动词或动词短语。

每个概念对应一个词

这里的概念指对同一类型的事物或操作的抽象，比如：针对接口对外提供的所有查询方法，“查询”这个概念可以对应这类查询操作。给每个抽象概念选一个词，并且一以贯之。比如针对“查询”这个概念，在定义接口的时候，可以用“query”这个词作为所有查询方法的前缀。

语境的使用

添加有意义的语境，你需要用有良好命名的类、函数或包来放置名称，给读者提供语境。如果这么做，给名称添加前缀就是最后一招了。设想在某个方法中看见一个单独的变量status，没有任何的语境能够说明status有什么用，但是加了前缀userStatus后，就不同了，至少我们可以将status和user关联起来。
不要添加没用的语境只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境。假设有一个名为“加油站豪华版”（Gas Station Deluxe）的应用，给每个类添加GSD前缀就不是什么好主意了。

怎么写注释（可读性）

什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。

好注释

有些注释是必须的，也是有力的。下面提供一些好注释的示例：类、方法的职责说明的注释代码中关键行的注释比如：

public ActionForward listForBan(){//获得当前用户UserInfo user = this.getUserInfo(request);//标识位，控制在审批列表默认显示查询区String noAddr = request.getParameter("noAddr");//…}

关于“获得当前用户”注释的说明，其实这段注释是可以省略的，前提getUserInfo方法换个名字getCurrentUserInfo。这也告诉我们注释是可以不需要的。

核心业务处理逻辑的注释 注意随着业务逻辑的调整，同时调整注释和代码。

警示用于警告其他程序员程序运行后会出现某种后果。比如：

public static SimpleDateFormat makeStandardHttpDateFormat(){//SimpleDateFormat is not thread safe,//so we need to create each instance independentlySimpleDateFormat df = new SimpleDateFormat(“yyyy-MM-dd”);return df;}

TODO注释公共API中的Javadoc

坏注释

大多数注释都属于坏注释。通常坏注释都是糟糕的代码的支撑或借口，或者是对错误决策的修正，基本上等于程序员自说自话。下面提供一些坏注释的的示例：

多余的注释下面的注释，可以算多余的注释：

示例1：/***日期规则 Default constructor*/public AnnualDateRule(){}示例2：/** The day of month */private int dayOfMonth示例3：
/************维护申请人Action开始*************************/      示例4：public static void main(String[] args){try{while(true){ //第一个while开始 *********************//此处省略110行}//第一个while结束 *********************while(){//第二个while开始 *********************}//第二个while结束 *********************}catch(Exception e){}}

关于“示例3”、“示例4”的特别说明，出现这种需要使用标记位来定位的情况，会使得我们的类或者方法太过庞大，可以考虑重构了。

误导性注释误导性主要指注释表达的意思和代码的实现不一致，给阅读代码的人带来一定的干扰。常见的情况，随着时间的推移，代码在不断的调整，但是注释没有做相应的调整。
注释掉的代码由于一些原因，程序员会选择注释前版本的代码，不会删除它，比如模块的调整需要将代码现在的版本还原到之前一个版本。听起来还是有些道理，不过我们可以使用源代码管理工具，实现不同版本的切换，并且注释掉的代码，会导致其他开发人员不敢动它，即使一段没用的注释代码，也可能会让其他开发人员去花时间琢磨该段代码的意图。

良好的代码排版（可读性）

在阅读一段没有缩进的代码时，阅读代码的人会觉得这段代码杂乱；代码块中存在过长的行代码又没有适当的换行，阅读代码的人需要移动鼠标拖动横向滚动条，才能整体把握这行代码的意图。以上所述，都是编写代码时不注意排版引起代码可读性降低的问题。这里说的排版主要包括：

代码缩进
适当换行在编辑工具中编辑窗口最大化时，每行代码的字符数控制在不出现横向滚动条。
一致的编写风格如果你的编码风格是：

If(true){//code}请不要出现这样的代码：If(true){//code}

良好的代码排版一定能够增强代码的可读性。

避免硬编码（可维护性）

很多时候，系统会依据其所处环境的不同而需要不同的配置。常见的情况有，生产环境和开发环境下系统的数据源配置是不一样的，系统中某个功能点会依据生产环境和开发环境的不同而配置不同的内容。

缺少经验的开发人员可能会将系统中本来应该设计成可变部分的代码用具体的字母或者数字代替，硬编码就产生了。项目中通常是由实施人员（非开发人员）负责系统的部署、维护，让他们修改代码中硬编码的内容，增大了系统的维护难度，也降低了代码的可维护性。

总结

这是以前整理的一份代码规范都是一些很基础的，同时也增加了一些实例，及说明。对于刚刚入行的新人来说还是具备一定的参考价值。这种代码规范一般每个公司可能都有一些个性化的要求，不过整体是一致的。想阿里的代码规范都免费提供给国内公司参考了。大家可以公众号：科比可比克回复关键字“码出高效”，免费下载“阿里巴巴java开发手册”。里面会有更多的规范的说明。如果公众号对你有点帮助，请关注。