在说代码规范之前，我们谈谈什么是路，鲁迅的《故乡》 原文结尾提到：“其实地上本没有路,走的人多了,也便成了路。”代码规范正如世上的路，代码原本只是为了实现某些功能，你可以任意的去写，但是大家慢慢的，习惯性的，在程序中都用同一种表示方法来实现某一个功能，于是就有了代码规范，然后所有的程序员都按照这个规范去写，就好比世上的路，通往一个地方的好路你不走，非要选沟沟坎坎的地方，你不是给自己找问题吗？再比如，本来国家没有交通规则，但是为了保证交通的畅通和人们出行的方便，国家制定了一系列的规则。所以，代码一定要规范。## 标题

1.1.代码规约能够保证代码风格的一致性： 因为在软件的整个生命周期中，软件的作者往往不是同一个人。如果大家都遵守这个规范，每个人的代码风格就会保持一致。 2.代码规约能够提升代码的可读性： 如果做到了代码风格的一致性，那么看到别人写的代码就和自己写的没有什么差距，这样就可以使程序员很快上手，很好的理解软件。

当你看到这样一段代码的时候，你心里肯定妈mmp。。。顿时心情不好了。。。 这段代码还是比较简单且代码量也是比较少的，所以看起来还不至于太难懂，但是当代码量达到上千甚至上万行时，如果代码还是这样的话，肯定是相当懵逼的，可能一个小小的功能你要看几个小时才能看懂，或者一个小小的bug你要调一天。。。

3.代码规约能够降低软件的维护成本： 大家知道软件的整个生命周期中，大概有80%的时间都是用来维护软件。如果都遵守这个代码规约，代码风格就会保持一致，代码的可读性就会提升，维护时间自然就会缩短。

1.需要 Map 的主键和取值时，应该迭代 entrySet

当循环中只需要 Map 的主键时，迭代 keySet 是正确的。但是，当需要主键和取值时，迭代 entrySet 才是更高效的做法，比先迭代 keySet 后再去 get 取值性能更佳。 反例：

正例：

2.应该使用Collection.isEmpty检测空

使用 Collection.size 来检测空逻辑上没有问题，但是使用 Collection.isEmpty使得代码更易读，并且可以获得更好的性能。任何 Collection.isEmpty 实现的时间复杂度都是 O(1) ，但是某些 Collection.size 实现的时间复杂度可能是 O(n) 。 反例：

正例：

3.不要把集合对象传给自己

此外，由于某些方法要求参数在执行期间保持不变，因此将集合传递给自身可能会导致异常行为。

反例：

4.集合初始化尽量指定大小 java 的集合类用起来十分方便，但是看源码可知，集合也是有大小限制的。每次扩容的时间复杂度很有可能是 O(n) ，所以尽量指定可预知的集合大小，能减少集合的扩容次数。

反例：

正例：

5.字符串拼接使用 StringBuilder

一般的字符串拼接在编译期 java 会进行优化，但是在循环中字符串拼接， java 编译期无法做到优化，所以需要使用 StringBuilder 进行替换。

反例：

6.List 的随机访问

大家都知道数组和链表的区别：数组的随机访问效率更高。当调用方法获取到 List 后，如果想随机访问其中的数据，并不知道该数组内部实现是链表还是数组，怎么办呢？可以判断它是否实现* RandomAccess *接口。 正例：

7.频繁调用 Collection.contains 方法请使用 Set 在 java 集合类库中，List 的 contains 方法普遍时间复杂度是 O(n) ，如果在代码中需要频繁调用 contains 方法查找数据，可以先将 list 转换成 HashSet 实现，将 O(n) 的时间复杂度降为 O(1) 。

反例：

8.长整型常量后添加大写 L

在使用长整型常量值时，后面需要添加 L ，必须是大写的 L ，不能是小写的 l ，小写 l 容易跟数字 1 混淆而造成误解。

正例：

9.不要使用魔法值

当你编写一段代码时，使用魔法值可能看起来很明确，但在调试时它们却不显得那么明确了。这就是为什么需要把魔法值定义为可读取常量的原因。但是，-1、0 和 1不被视为魔法值。

反例：

正例：

10.不要使用集合实现来赋值静态成员变量

对于集合类型的静态成员变量，不要使用集合实现来赋值，应该使用静态代码块赋值。

反例：

正例：

11.建议使用 try-with-resources 语句

Java 7 中引入了 try-with-resources 语句，该语句能保证将相关资源关闭，优于原来的 try-catch-finally 语句，并且使程序代码更安全更简洁。

反例：

正例：

12.删除未使用的私有方法和字段

删除未使用的私有方法和字段，使代码更简洁更易维护。若有需要再使用，可以从历史提交中找回。

反例：

正例：

13.删除未使用的局部变量

删除未使用的局部变量，使代码更简洁更易维护。

反例：

正例：

14.删除未使用的方法参数

未使用的方法参数具有误导性，删除未使用的方法参数，使代码更简洁更易维护。但是，由于重写方法是基于父类或接口的方法定义，即便有未使用的方法参数，也是不能删除的。

反例：

正例：

15.删除表达式的多余括号

对应表达式中的多余括号，有人认为有助于代码阅读，也有人认为完全没有必要。对于一个熟悉 Java 语法的人来说，表达式中的多余括号反而会让代码显得更繁琐。 反例：

正例：

16.工具类应该屏蔽构造函数

工具类是一堆静态字段和函数的集合，不应该被实例化。但是，Java 为每个没有明确定义构造函数的类添加了一个隐式公有构造函数。所以，为了避免 java "小白"使用有误，应该显式定义私有构造函数来屏蔽这个隐式公有构造函数。

反例：

正例：

17.删除多余的异常捕获并抛出

用 catch 语句捕获异常后，什么也不进行处理，就让异常重新抛出，这跟不捕获异常的效果一样，可以删除这块代码或添加别的处理。

反例：

正例：

18.公有静态常量应该通过类访问

虽然通过类的实例访问公有静态常量是允许的，但是容易让人它误认为每个类的实例都有一个公有静态常量。所以，公有静态常量应该直接通过类访问。

反例：

正例：

20.使用String.valueOf(value)代替""+value

当要把其它对象或类型转化为字符串时，使用 String.valueOf(value) 比""+value 的效率更高。

反例：

正例：

21.过时代码添加 @Deprecated 注解

当一段代码过时，但为了兼容又无法直接删除，不希望以后有人再使用它时，可以添加 @Deprecated 注解进行标记。在文档注释中添加 @deprecated 来进行解释，并提供可替代方案

正例：

22.禁止使用构造方法 BigDecimal(double)

BigDecimal(double) 存在精度损失风险，在精确计算或值比较的场景中可能会导致业务逻辑异常。

反例：

正例：

23.返回空数组和空集合而不是 null

返回 null ，需要调用方强制检测 null ，否则就会抛出空指针异常。返回空数组或空集合，有效地避免了调用方因为未检测 null 而抛出空指针异常，还可以删除调用方检测 null 的语句使代码更简洁。

反例：

正例：

24.优先使用常量或确定值来调用 equals 方法

对象的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals 方法。当然，使用 java.util.Objects.equals 方法是最佳实践。

反例：

正例：

25.枚举的属性字段必须是私有不可变

枚举通常被当做常量使用，如果枚举中存在公共属性字段或设置字段方法，那么这些枚举常量的属性很容易被修改。理想情况下，枚举中的属性字段是私有的，并在私有构造函数中赋值，没有对应的 Setter 方法，最好加上 final 修饰符。

反例：

正例：

26.小心String.split(String regex)

字符串 String 的 split 方法，传入的分隔字符串是正则表达式！部分关键字（比如.[]| 等）需要转义

反例：

正例：

网上关于springboot的内容实在太多了，我就选一些给大家分享一下吧，为了得到大家的支持，我现在将这份笔记送给亲亲们

1）独立运行的 Spring 项目 Spring Boot 可以以 jar 包的形式独立运行，运行一个 Spring Boot 项目只需通过 java–jar xx.jar 来运行。 2）内嵌 Servlet 容器 Spring Boot 可选择内嵌 Tomcat、Jetty 或者 Undertow，这样我们无须以 war 包形式部署项目。 3）提供 starter 简化 Maven 配置 Spring 提供了一系列的 starter pom 来简化 Maven 的依赖加载，例如，当你使用了spring-boot-starter-web 时，会自动加入如图 1 所示的依赖包。 4）自动配置 Spring Spring Boot 会根据在类路径中的 jar 包、类，为 jar 包里的类自动配置 Bean，这样会极大地减少我们要使用的配置。当然，Spring Boot 只是考虑了大多数的开发场景，并不是所有的场景，若在实际开发中我们需要自动配置 Bean，而 Spring Boot 没有提供支持，则可以自定义自动配置。 5）准生产的应用监控 Spring Boot 提供基于 http、ssh、telnet 对运行时的项目进行监控。 6）无代码生成和 xml 配置 Spring Boot 的神奇的不是借助于代码生成来实现的，而是通过条件注解来实现的，这是 Spring 4.x 提供的新特性。Spring 4.x 提倡使用 Java 配置和注解配置组合，而 Spring Boot 不需要任何 xml 配置即可实现 Spring 的所有配置。

1）优点 快速构建项目。 对主流开发框架的无配置集成。 项目可独立运行，无须外部依赖Servlet容器。 提供运行时的应用监控。 极大地提高了开发、部署效率。 与云计算的天然集成。 2）缺点 版本迭代速度很快，一些模块改动很大。 由于不用自己做配置，报错时很难定位。 网上现成的解决方案比较少。

大部分 Java 应用都需要访问数据库，尤其是服务层，所以，SpringBoot 会为我们自动配置相应的数据访问设施。

若想 SpringBoot 为我们自动配置数据访问的基础设施，那么，我们需要直接或者间接地依赖 spring-jdbc，一旦 spring-jdbc 位于我们 SpringBoot 应用的 classpath，即会触发数据访问相关的自动配置行为，最简单的做法就是把 spring-boot-starter-jdbc 加为应用的依赖。

默认情况下，如果我们没有配置任何 DataSource，那么，SpringBoot 会为我们自动配置一个基于嵌入式数据库的 DataSource，这种自动配置行为其实很适合于测试场景，但对实际的开发帮助不大，基本上我们会自己配置一个 DataSource 实例，或者通过自动配置模块提供的配置参数对 DataSource 实例进行自定义的配置。

假设我们的 SpringBoot 应用只依赖一个数据库，那么，使用 DataSource 自动配置模块提供的配置参数是最方便的：

当然，自己配置一个 DataSource 也是可以的，SpringBoot 也会智能地选择我们自己配置的这个 DataSource 实例（只不过必要性真不大）。

除了 DataSource 会自动配置，SpringBoot 还会自动配置相应的 JdbcTemplate、DataSourceTransactionManager 等关联“设施”，可谓服务周到，我们只要在使用的地方注入就可以了：

不过，spring-boot-starter-jdbc 以及与其相关的自动配置也不总是带来便利，在某些场景下，我们可能会在一个应用中需要依赖和访问多个数据库，这个时候就会出现问题了。

假设我们在 ApplicationContext 中配置了多个 DataSource 实例指向多个数据库：

那么，不好意思，启动 SpringBoot 应用的时候会抛出类似如下的异常（Exception）：

为了避免这种情况的发生，我们需要在 SpringBoot 的启动类上做点儿“手脚”：

也就是说，我们需要在这种场景下排除掉对 SpringBoot 默认提供的 DataSource 相关的自动配置。但如果我们还是想要享受 SpringBoot 提供的自动配置 DataSource 的机能，也可以通过为其中一个 DataSource 配置添加 org.springframework.context.annotation.Primary 这个 Annotation 的方式以实现两全其美：

另外，SpringBoot 还提供了很多其他数据访问相关的自动配置模块，比如 spring-boot-starter-data-jpa、spring-boot-starter-data-mongodb 等，大家可以根据自己数据访问的具体场景选择使用这些自动配置模块。

如果选择了 spring-boot-starter-data-jpa 等关系数据库相关的数据访问自动配置模块，并且还需要同时依赖访问多个数据库，那么，也需要相应的在 SpringBoot 启动类中排除掉这些自动配置模块中的 AutoConfiguration 实现类（对应 spring-boot-starter-data-jpa 是 JpaRepositoriesAutoConfiguration），或者标注某个 DataSource 为 @Primary。

符合web标准(UTF-8，HTML5)，语义化html (HTML5新增要求，减少div和span等无特定语义的标签使用)，结构表现行为分(HTML-CSS-JS代码分离, 不同行为代码高内聚低 耦合)，兼容性优良(早期版本浏览器兼容，移动端和PC端设备兼容)。页面性能方面(减少请求次数，例如使用精灵图和sass语法)，代码要求简洁明了有序，尽可能的减小服务器负载，保证最快的解析速度(减小repaint和reflow) 。

1、html, css, js, lib, images文件均存放至项目的目录中。如果使用相关前端框架，根据 框架的文件格式进行合理布局。 2、所有文件夹吸文件使用英文命名(避免使用中文路径)。 3、html文件: 入口文件使用index.html。如果有对应的设计组设计原稿，要将对应的设计稿和html文件命名一致并合理存放。 4、css文件命名:后缀.css。 通用initial.css, 初始化base.css,首页index.css, 其他页面按照对应的html命名。 5、Js文件命名:文命名，后缀js.通用common.js, 初始化base.js。 其他页面按照对应的html命名。

1、文档类型声明及编码:统一为html5声明类型。写时利用IDE实现层次分明的缩进(默认 缩进4空格)。 2、 非特殊情况下CSS文件放在body部分标签后。非特殊情况下大部分JS文件放在标签尾部(如果需要界面未加载前执行的代码可以放在head标签后)避免行内JS和CSS代码。 3、所有编码需要遵循html (XML) 标准， 标签&属性&属性命名必须由小写字母及下划线数字组成，且所有标签必须闭合,包括br()，hr()等。 属性值用双引号。 4、 引入JS库文件,文件名须包含库名称及版本号及是否为压缩版,比如jquery-1.4.1.minjs。 引入插件,文件名格式为库名称+插件名称,比如jQuery.bootstrap.js。 5、 书写页面过程中，请考虑向后扩展性。class&id参见css书写规范。 6、 需要为html元素添加自定义属性的时候，首先要考虑下有没有默认的已有的合适标签去设置,如果没有，可以使用须以"data- “为前缀来添加自定义属性，避免使用"data: “等其他命名方式。 7、语义化html,如标题根据重要性用h*(同一页面只能有一个h1),段落标记用p，列表用ul, 内联元素中不可嵌套块级元素。 8、 尽可能减少div多层级嵌套。 9、 书写链接地址时，必须避免重定向,例如: href= “http: //myVue.com/” ，即必须在URL 地址后面加上”/”; 10、 页面中尽量避免使用style属性, 即"style=…" 。 11、 必须为含有描述性表单元素(input, textarea)添加label, 如姓名: 写成: 姓名: 12、能以背景形式呈现的图片,尽量写入css样式中。 13、 重要图片必须加上alt属性。 给重要的元素和截断的元素加上title。 14、 给区块代码及重要功能(此如循环)加上注释，方便后台添加功能。 15、 特殊符号使用:尽可能使用代码替代:比如)&空格()&>(>)等等。

1、 编码规范为utf-8。 2、 协作开发及分工: i会根据各个模块，同时根据页面相似程序,事先写**体框架文件,分配给前端人员实现内部结构&表现&行为。共用css文件base.css由i书写，协作开发过程中，每个页面请务必都要引入，此文件包含reset及头部底部样式，此文件不可随意修改。 3、class与id的使用: id是唯一 的并是父级的，class是可以重复的并是子级的，所以id仅使用在大的模块上, class可用在重复使用率高及子级中。id原则上都是由我分发框架文件时命名的，为JS预留钩子的除外。 4、为JS预留钩子的命名，请以js_ 起始，比如: js_ hide, js_ show。 5、 class与id命名:大的框架命名比如header/footer/wrapper/left/right之类的在2中由i统一命名，其他样式名称由小写英文&数字&来组合命名，如i_ comment, fontred,width200。 避免使用中文拼音,尽量使用简易的单词组合。总之，命名要语义化，简明化。 6、 规避class与id命名(此条重要,若有不明白请及时与沟通): a)通过从属写法规避, 示例见d。 b)取父级元素id/class命名部分命名,示例见d。 c)鳆使用率高的命名，请以自己代号 加下划线起始，比如i_clear。 d) a, b两条，适用于在2中已建好框架的页面，如要在2中已建好框架的页面代码中加入新的div元素，按a命名法则: … ,样式写法: #mainnav.firstnav{…}_按 b命名法则 : … 样式写法: .main_firstnav{…} 7、 css属性书写顺序，建议遵循:布局定位属性->自身属性- >文本属性- >其他属性.此条可根据自身习惯书写,但尽量保证同类属性写在一起，属性列举:布局定位属性主要包括: display&list- style&position (相应的top， right, bottom, left) & float&clear & visibility & overflow;自身属性主要包括: width&height&margin&padding&border&background. 文本属性主要包括: color&font&text-decoration&text- align&vertical-align&white- space& 其他&content。 8、 书写代码前，提高样式重复使用率。 9、 分利用htmI自身属性及样式继承原理减少代码量， 例如: 即可实现日期居右显示 ul.ist li { position: relative ul .list li span { position: absolute; right: 0 } 10、 样式表中中文字体名，务必转码成unicode码，以避免编码错误时乱码。 11、 背景图片请尽可能使用精灵图技术，减小http请求， 考虑到多人协作开发，精灵图按模块制作。 12、 使用table标签时(尽量避免使用table标签), 请不要用 width/height/cellspacing/cellpadding等table属性直接定义表现， 应尽可能的利用table自 身私有属性分离结构与表现，如thead, tr, th, td, tbody, tfoot, colgroup, scope。 (cellspaing及cellpadding的css控制方法: table{border: 0。margin: 0。 border-collapse: collapse。 }tableth, tabletd{padding: 0。}, base.css文件中我会初始化表格样式） 13、 杜绝使用兼容ie8。 14、 用png图片做图片时，要求图片格式为png-8格式，若png- 8实在影响图片质量或其中有半透明效果，要为ie6单独定义背景。

15、 避免兼容性属性的使用，比如text-shadowl|css3的相关属性。 16、 减少使用影响性能的属性，比如position: absolutel|float。 17、 必须为大区块样式添加注释,小区块适量注释。 18、 代码缩进与格式:建议单行书写，可根据自身习惯,后期优化会统一处理。

1、 文件编码统一为utf-8,书写过程中，每行代码结束必须有分号。原则上所有功能均根据XXX项目需求原生开发,以避免网上down下来的代码造成的代码污染。 2、 库引入:原则上仅引入jQuery库, 若需引入第三方库,须与团队其他人员讨论决定。 3、 变量命名:驼峰式命名原生JS变要求是纯英文字母，首字母须小写，如myVue。jQuery变量要求首字符为’_ ’，其他与原生JS规则相同，如： _myVue。 另外要求变集中声明，避兔全局变量。 4、 类命名:首字母大写，驼峰式命名.如MyVue。

5、 函数命名:首字母小写驼峰式命名.如myVue()。 6、 命名语义化,尽可能利用英文单词或其缩写。 7、 尽量避免使用存在兼容性及消耗资源的方法或属性，比如eval r()&innerText。 8、后期优化中，JS非注释类中文字符须转换成unicode编码使用，以避免编码错误时乱码显示。 9、 代码结构明了，加适量注释提高函数重用率。 10、 注重与html分离, 减小reflow, 注重浏览器性能

1、 所有页面元素类图片均放入img文件夹，测试用图片放于demo文件夹。 2、 图片格式gif/png/jpg. 提倡使用webp文件格式，使用软件进行图片压缩。 3、 命名全部用小写英文字母数字|的组合,其中不得包含汉字空格特殊字符;尽量用易懂 的词汇,便于团队其他成员理解。另,命名分头尾两部分,用下划线隔开，比如 ad_ left01.giflbtn_ submit.gif. 4、 在保证视觉效果的情况下选择最小的图片格式与图片质量,以减少加载时间。 5、 尽量避免使用半透明的png图片(若使用，请参考css规范相关说明)。 6、 运用css精灵图技术集中小的背景图或图标，减小页面http请求， 但注意， 请务必在对应的psd源图中划参考线，并保存至img目录下。

开发及测试工具约定建议使用Aptana- Sublime-Vim-WebStrom, 亦可根据自己喜好选择，但须遵循如下原则: 1、 不可利用IDE的视图模式’ 画’代码。 2、 不可利用IDE生成相关功能代码。 B、 编码必须格式化，比如缩进。测试工具:前期开发仅测试FireFox&IE6&IE7&IE8,后期优 化时加入Opera&Chrome&Safari。 建议测试顺序: FireFox-> IE- > Opera-> Chrome-> Safari.

新手上路，车技不好，请各位扶好。希望大家多多支持，祝大家前程什锦，money不断。为了美好的明天，让我们一起努力吧！