即日起在codingBlog上分享您的技术经验即可获得积分,积分可兑换现金哦。

我的编程规范

编程语言 gg782112163 13℃ 0评论
本文目录
[隐藏]

1.编码规范

1.1.Google Java 规范

1.1.1.命名

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

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

public class ClassName { 
... 

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

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

public void toString() { 
   ... 
} 
  1. 常量: 全大写,单词之间用下划线分隔。
private static final NUMBER = 5; 
  1. 命名一定要选用有意义的单词,禁止使用单个字母,异常处除外。

  2. 避免使用长的名字

1.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.guavagroupId> 
   <artifactId>guavaartifactId> 
   <version>18.0version> 
dependency> 
  1. 日志类库使用slf4j,实现使用logback,方便配置,效率高于log4j。


<dependency> 
   <groupId>org.slf4jgroupId> 
   <artifactId>slf4j-apiartifactId> 
   <version>1.7.7version> 
dependency> 
<dependency> 
   <groupId>ch.qos.logbackgroupId> 
   <artifactId>logback-classicartifactId> 
   <version>1.1.7version> 
dependency> 

2.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类型存储日期,二者效率差的不是一个数量级,抓着直接打死。

3.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>devid> 
       <properties> 
           <deploy.type>devdeploy.type> 
       properties> 
       <activation> 
           <activeByDefault>trueactiveByDefault> 
       activation> 
   profile> 
   <profile> 
       <id>prodid> 
       <properties> 
           <deploy.type>proddeploy.type> 
       properties> 
   profile> 
profiles> 
<build> 
   <resources> 
       <resource> 
           <directory>src/main/resourcesdirectory> 
       resource> 
       <resource> 
           <directory>src/main/resources.${deploy.type}directory> 
       resource> 
   resources> 
build> 
  1. 配置文件统一放在maven规范的resource目录下,不要直接放在classpath根目录

4.git规范

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

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

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

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

  • 分支开发,功能开发完成后测试,打tag,发布线上,3日内稳定无bug后合并到master主干,保证后期线上和主干代码的一致。


    tag格式:{发布日期(yyyyMMdd)}_{当日第几次发布}_{发布人}_{发布版本说明}

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

初始化创建与开发 

a) git clone  
b) git pull   
c) git checkout  -b   //为开发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  

e) git push   origin  separate_w_r:separate_w_r     

将本地分支  separate_w_r 推送到远程分支 

4.1.Linux 操作规范

4.1.1.1.1.1 操作规范

  1. 对于需要执行 mv 操作的动作,请谨慎 
  2. 严格区分文件与文件夹的操作,切勿统一处理 :

    • 对于文件夹执行 -r / -R 操作, 对于文件不要在携带递归参数。
    • 禁止一律按照文件夹的操作统一执行。尤其是在执行删除操作时候。
  3. 删除操作时候要再次确认自己的命令目标是否是正确的。
  4. 删除操作要携带路径。
  5. 查看文件时候区分处理 :

    • 一般文件的查看请使用 cat 来处理
    • 对于日志文件可以使用 vim 来查看,禁止打开修改, 退出使用 :q

4.1.1.2.1.2 文件命名规范:

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

4.2.2. 项目规范

4.2.1.1.2.1 项目过程规范

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

4.2.1.2.2.2 部署系统操作 :

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

转载请注明:CodingBlog » 我的编程规范

喜欢 (0)or分享 (0)
发表我的评论
取消评论

*

表情