我的编程规范

编码规范

Google Java 规范

命名

1. 包名： 全小写字母，无下划线，单词之间用点分隔割。

2. 类名： 驼峰式，开头字母大写，无下划线。

public class ClassName { ... } 

1. 成员变量，参数，临时变量：驼峰式命名，开头字母小写，无下划线

2. 方法： 驼峰式命名，开头字母小写。

public void toString() {    ... } 

1. 常量： 全大写，单词之间用下划线分隔。

private static final NUMBER = 5; 

1. 命名一定要选用有意义的单词，禁止使用单个字母，异常处除外。

2. 避免使用长的名字

编码

1. 代码文件统一使用UTF-8编码

2. 缩进使用4空格，禁用制表符\t

3. 注释

   • 方法要有注释，包括功能描述，参数说明，注释写在方法上方

/** * author: 作者，如果跟类作者是同一人可以省略 * desc: 方法功能描述 * @param arg1 xxxx * @param arg2 xxxx */ public void func(T arg1, E arg2) {    ... } 

• 成员变量，注释写在成员变量上方，描述变量的含义

• 类：

/** * author: houying * date  : 16-11-25 * desc  : 类功能描述 */ public class XXXX { } 

• 当然最好的注释就是代码可以自解释，可读性非常强

  1. 异常处理

• 禁止吞异常：要么打日志，要么重新抛出

• 异常转换一定要打日志

• finally资源释放

  1. 函数长度控制在80行以内

  2. 每行的字符数量控制在100字符以内，超过的部分在第二行要有相对上一行8个空格的缩进。

  3. 嵌套不要超过两层，如果逻辑上确实有需要的话可以封装成函数易于理解。

  4. 连续超过5行代码在超过两处使用要封装成函数，降低代码重复率

  5. 第三方工具类库使用guava

<dependency>    <groupId>com.google.guava</groupId>    <artifactId>guava</artifactId>    <version>18.0</version> </dependency> 

1. 日志类库使用slf4j,实现使用logback，方便配置，效率高于log4j。比
   较

<dependency>    <groupId>org.slf4j</groupId>    <artifactId>slf4j-api</artifactId>    <version>1.7.7</version> </dependency> <dependency>    <groupId>ch.qos.logback</groupId>    <artifactId>logback-classic</artifactId>    <version>1.1.7</version> </dependency> 

mysql数据库使用规范

1. 数据库名称，表名和字段名称统一使用unix风格命名，即单词+下划线。

2. 没有特殊需求的主键统一使用id自增主键，禁用mysql的外键机制，但业务逻辑上需要的由应用程序保证。

3. 业务逻辑复的数据模型的设计要尽量满足第三范式。

4. 数据报表类项目由于数据大多数是由mr算好再导入到mysql表中的，明显的读多写少，建议使用myisam引擎，而非innodb引擎。二者区别：[传送门](htt
   p://blog.csdn.net/xifeijian/article/details/20316775)。

5. 对日期类型的存储：根据需要选择date或datetime类型，禁止使用varchar类型存储日期，二者效率差的不是一个数量级，抓着直接打死。

maven使用规范

maven本身是一个项目构建和依赖管理工具

1. 所有涉及到第三方jar包的管理统一使用maven工具，禁止使用手动创建lib目录拷贝jar包的行为，禁止使用手动创建lib目录拷贝jar包的行为，禁止使
   用手动创建lib目录拷贝jar包的行为！重要的事情说三遍。
2. 建议使用dependencyManagement管理依赖的jar包版本，在dependencies里配置实际依赖的第三方jar包，这样可避免同包下的不同版本冲突
3. 在开发阶段涉及到不同环境的配置文件时，使用如下配置方式在打包时通过制定-P参数来指定不同环境的配置文件:

mvn compile package -P dev 

or

mvn compile package -P prod 

<profiles>    <profile>        <id>dev</id>        <properties>            <deploy.type>dev</deploy.type>        </properties>        <activation>            <activeByDefault>true</activeByDefault>        </activation>    </profile>    <profile>        <id>prod</id>        <properties>            <deploy.type>prod</deploy.type>        </properties>    </profile> </profiles> <build>    <resources>        <resource>            <directory>src/main/resources</directory>        </resource>        <resource>            <directory>src/main/resources.${deploy.type}</directory>        </resource>    </resources> </build> 

1. 配置文件统一放在maven规范的resource目录下，不要直接放在classpath根目录

git规范

• IDE的配置文件使用.gitignore忽略，禁止上传到git仓库

• commit的时候尽量写明本次提交相对之前做的改动

• maven输出目录target禁止上传到git仓库

• 第三方jar包禁止上传到git仓库

• 分支开发，功能开发完成后测试，打tag，发布线上，3日内稳定无bug后合并到master主干，保证后期线上和主干代码的一致。
  tag格式：{发布日期(yyyyMMdd)}_{当日第几次发布}_{发布人}_{发布版本说明}

• 新分支名称采用： {需求名称(单词之间使用下划线)}-{日期(yyyyMMdd)}-{创建分支人员名称} 的格式命名，若为修改bug则需求名称统一为bugfix

初始化创建与开发 a) git clone <repo> b) git pull   c) git checkout  -b  <feartureA_br> //为开发fearture A建立的 branch分支。 不允许在master上直接修改 d) git branch //查看是否已经在分支上 e) git add /rm   commit //开发  f) git commit –amend //    以最后一次可修改方式提交  到目前为止，开发提交都是在 本地feartureA 上做的提交 正式提交到master上  a) git checkout master // 切换到master分支 b) git pull // master更新为最新 c) git checkout fetchA_br d) git rebase master // rebase master，根据冲突进行修改，确认后，git add <conflit file> e) git push   origin  separate_w_r:separate_w_r     将本地分支  separate_w_r 推送到远程分支 

Linux 操作规范

1.1 操作规范

1. 对于需要执行 mv 操作的动作，请谨慎　
2. 严格区分文件与文件夹的操作，切勿统一处理 :
   
   • 对于文件夹执行 -r / -R 操作, 对于文件不要在携带递归参数。
   • 禁止一律按照文件夹的操作统一执行。尤其是在执行删除操作时候。
3. 删除操作时候要再次确认自己的命令目标是否是正确的。
4. 删除操作要携带路径。
5. 查看文件时候区分处理 :
   
   • 一般文件的查看请使用 cat 来处理
   • 对于日志文件可以使用 vim 来查看，禁止打开修改， 退出使用 :q

1.2 文件命名规范：

1. 允许字符包括 . , -, 小写的英文字符
2. 字符点 . 出现在文件命名中，用来说明文件的类型
3. 当命名中出现多个单词时候，使用字符 -分割。
4. 用首字母代替单词时允许使用大写字符。

2. 项目规范

2.1 项目过程规范

1. 每一个项目都应该拥有 README.md， 位置在项目主目录下， 使用 wiki Markdown 规范。
2. 临时产生的文件及杂项放置到项目 tmp 目录下。
3. 创建代码工程时需要在项目下创建项目的工程文件夹。 项目说明放置到工程 doc 文件夹下，文本文档使用说明使用 wiki Markdown 规范。

2.2 部署系统操作 :

1. 系统统一按照 ${系统名称}-${版本}-${上线日期} 的格式，
2. 所有的文件名称请使用复制加粘贴完成，禁止使用手动敲，甚至不允许使用 tab 补全。
3. 保留部署到上线过程中的所有的日志， 禁止执行删除操作。