lamp网站开发经验,做网站如何分页,wordpress邀请会员,设计师逛的网站开发团队在开发过程中#xff0c;由于每个人的开发习惯#xff0c;以及对于技术的理解深浅程度不一#xff0c;往往一个项目在开发过程中#xff0c;代码的质量#xff0c;代码的风格都不尽相似#xff0c;所以有一份适合团队的代码规范是非常有必要的#xff0c;而一个… 开发团队在开发过程中由于每个人的开发习惯以及对于技术的理解深浅程度不一往往一个项目在开发过程中代码的质量代码的风格都不尽相似所以有一份适合团队的代码规范是非常有必要的而一个团队的代码规范包含了开发常见的风格习惯以及一些常见代码细节的写法规范等本篇就来浅谈一些代码规范涉及的技术细节和对这些部分的思考。命名规范相信经历过项目开发的人都知道在开发过程中会涉及无数次的申明操作这个过程中最让人头疼的就是给申明的文件(实例)起个名字了。名字需要准确的表达出背后代表的含义并且还要通俗易懂使得代码干净漂亮否则不好的命名反而成为开发的阻碍干扰维护者和开发者的思路。那么一个好的命名会给我们开发带来什么好处呢为标识符提供附加的信息赋予标识符现实意义。帮助我们理顺编码的逻辑减少阅读和理解代码的工作量使代码审核变得更有效率专注于更重要的问题而不是争论语法和命名规范这类小细节提高开发效率提高代码的清晰度、可读性以及美观程度避免不同产品之间的命名冲突。那么常见的命名方式有哪些呢根据各大规范和Java框架主流的方案来说一般分为四种驼峰命名法驼峰命名法基本上是各大企业使用最多也是各大规范首推的命名方式。其使用大小写混合的格式单词之间不使用空格隔开或者连接字符连接的命名方式因此发展处两种格式大驼峰命名法(UpperCamelCase)和小驼峰命名法(lowerCamelCase)这两种命名方式的区别主要在第一个单词的首字母上大驼峰命名法则是首字母大写命名而小驼峰则是首个单词的首字母小写比如firstName, toString等。在jdk中参照了谷歌制定的驼峰命名转换规则用来细分不同情况下的驼峰转换:1.从正常的表达形式开始把短语转换成 ASCII 码并且移除单引号,如“Müller’s algorithm”转换为“Muellers algorithm”2.如果存在连接符号就将连接符开始分割为两个单词如果某个分割前某个单词已经是驼峰命名也拆分为小写的两个单词如AdWords会转换为ad words而non-current则转换为non current 等3.将所有的字母转为小写字母每个单词的首字母大写就转换为了大驼峰命名/首字母小写则转为小驼峰4.将所有的单词连接在一起即为标示符命名例如下面的转换案例蛇形命名法蛇形命名法在Java中极少见到一般为每个单词之间都通过‘’进行连接例如‘outof’串式命名法串式命名法和蛇形规则一样唯一区别是每个单词之间通过-连接例如out-of匈牙利命名法匈牙利命名法在Java早期的框架中开始出现由一个或者多个小写字母开始使用这些字母作为标示符用来标记当前命名的变量的用途例如:usName(表示是用户的名称),lAccountNum(表示是Long类型的长整数)等而在jdk中针对每一种类型的命名有特定的规范针对每一种编码规范来组合使用在不同场景的命名中如下总结下来jdk命名遵循了三点1.命名有准确的意义绝不使用单词缩写或者单词的部分例如GoodsItem绝不会命名为GdItem2.严格遵守命名规范决不允许一个规则内出现多个规范混用的情况例如在一个命名中同时出现驼峰命名与蛇形命名等3.尽量将可读性的命名放在前面开发者的习惯一般都是从左到右开始阅读和编码所以将能体现出想要的信息的内容优先放在前面例如BeijingTime和TimeBeijing的区别变量申明的时机前面我们说过命名的规范那么申明变量是否也需要规范呢其实也需要例如现在申明一个类型的变量的时候往往有人喜欢一个类型的变量在一行内申明完毕例如int size, length;甚至于出现了一行申明了七八个属性的情况或者是在一行内申明了好几个类型的变量例如int size,entity[];//一行申明多个不同类型变量看起来代码似乎节省了但是对于开发和维护来说其实反而更容易忽略错误更重要的是申明类型是数组的时候不要把基本类型和[]分开因为int[] 才是代表了一个类型的整体分开申明容易被忽略或者埋下隐患的错误所以往往建议每一行仅申明一个变量如下int size;int[] entity;在开发中往往还存在另外一个情况就是方法内申明局部变量的时候往往喜欢在方法开始的时候就创建或者申明该变量但是使用的时机往往在n行代码以后甚至于到后面这个申明的变量并没有使用到由于间隔太远也没有关注后面就成了一个死变量这种情况是很多见的而反观jdk的规范中可以看到都是在需要使用变量的时候创建或者在需要使用的前几行代码申明再去创建例如public void test(String userName){ Account userAccount; String groceryStoreName; //中间一堆业务代码和操作 /***** **** ***/ //通过用户名获取userAccount userAccount AccountManager.getUserAccount(userName); if(userAccount null){ //为null的操作抛异常 } //再去获取名称 groceryStoreName userAccount.getGroceryStoreName(); if(groceryStoreName null){ //为null抛异常 } //后续一堆业务代码}但是我们看下规范后的写法public void test(String userName){ //中间一堆业务代码和操作 /***** **** ***/ //通过用户名获取userAccount Account userAccount AccountManager.getUserAccount(userName); if(userAccount null){ //为null的操作抛异常 } //再去获取名称 String groceryStoreName userAccount.getGroceryStoreName(); if(groceryStoreName null){ //为null抛异常 } //后续一堆业务代码}很明显的可以看出来代码更清晰明了也更有逻辑性。另外在申明类属性变量的时候我们建议将变量申明在一起分块存放不建议在类中变量和方法混合在一起使用例如另外在申明类变量的时候切记不要忘记类变量如果是基础类型会有默认值如非必要在类属性创建中建议使用包装类型防止因默认值带来的数据不一致等问题而在方法内创建局部变量的时候由于基本类型变量没有默认值需要手动申明值反而建议使用基本类型而不是使用包装类这样同样也可以尽量避免无意的拆箱、装箱行为在数十万次百万次的情况下对于程序也会造成一定的影响。if与大括号if语句是我们开发中最常见的逻辑分支语句之一同样的在java中if也会有一些简洁写法例如逻辑业务仅有一行代码的时候我们可以省去大括号直接在if下一行编写业务代码如下if(flag) count ;//if以外的逻辑 user.setAge(10);......但是熟悉规范的都知道无论是阿里规范还是jdk的规范都不推荐使用简化代码这是为什么呢这让我想起了2014年苹果的ios系统爆出来的一个严重安全漏洞(“GoTo Fail 漏洞”)而这个漏洞就和大括号有关系而对应漏洞的代码大概可以理解为这样 if ((error doSomething()) ! 0) goto fail; //无论如何都是走到这里下面再也触发不了了 goto fail; if ((error doMore()) ! 0) goto fail;fail:return error;是不是看出来什么了没错如果前面的条件生效就会跳转到fail的操作返回error但是如果不满足也会跳转到fail那么也就是说后续的业务代码无论如何也触发不了了其实了解这个问题的人其实大概可以猜出来这里就是多写了一个goto fail;导致编译器认为了别的业务代码但是假设我们加了大括号这个问题就会迎刃而解例如 if ((error doSomething()) ! 0) { goto fail; //无论如何都是走到这里下面再也触发不了了 goto fail; } if ((error doMore()) ! 0) goto fail;fail:return error;其实这个时候就会发现即使是多写了一行代码也不会影响整个业务的逻辑减少了bug产生。看到这里我们似乎明白了为什么各大规范都建议不省略大括号的写法了。包装类与基本类型做Java开发的都知道Java中默认有八种基本类型但是同样的也有八种对应的包装类型很多时候企业开发和使用的时候对于包装类型和基本类型的使用并不规范往往会导致一部分小的隐患的发生。前面我们有介绍建议在类属性申明的时候使用包装类型而在方法内建议使用基本类型这里我们可以再去思考两个开发的时候常用的使用场景1.判断两个数值类型的值是否相等2.创建数值类型看过阿里手册和JDK规范的应该知道里面都有一条规范明确指出基本数值类型的包装类型在比较的时候不允许使用的方式而是使用equals这是为什么呢我们来看看一个例子Integer a 100, b 100, c 150, d 150;System.out.println(a b);//trueSystem.out.println(c d);//false可以看到两个Integer类型的变量值一样的情况下比较的结果居然是false我们通过断点的方式知道 Integer var ? 形式声明变量会通过 java.lang.Integer#valueOf(int) 来构造 Inte ger 对象我们来看看valueOf方法的源码public static Integer valueOf(int i) { if (i IntegerCache.low i IntegerCache.high) return IntegerCache.cache[i (-IntegerCache.low)]; return new Integer(i);}可以看到会去判断value的值是否在IntegerCache的范围内如果在就会使用IntegerCache中缓存的实例不存在才会创建新的Integer实例这个缓存的值默认是-128到127之间并且是可以通过配置环境变量的方式动态改变的这点可以从IntegerCache源码中看到privatestaticclassIntegerCache{staticfinalint low -128;staticfinalint high;staticfinalInteger cache[];static{// high value may be configured by propertyint h 127;String integerCacheHighPropValue sun.misc.VM.getSavedProperty(java.lang.Integer.IntegerCache.high);// 省略其它代码}// 省略其它代码}从这我们也可以看出问题2的答案为什么很多规范都推荐构建实例的时候是Integer a 5;的形式而不是new Integer(5)的原因可以减少实例的创建复用缓存对象。接着我们再来看第一个问题比较和equals比较的区别在哪我们知道比较的是两个实例对象的内存地址而equals则是比较的具体的实现而基本类型的包装类实现实例如果不在缓存范围内肯定不是同一个对象逻辑上内存地址肯定是不一样的所以在超过缓存范围后比较的结果并不准确那么我们该如何比较呢事实上基本类型的包装类中都有获取具体value的方法例如Integer中就有intValue的方法获取具体的值类型为基本类型这样我们再去比较就可以了那么equlas方法为什么可以比较呢我们就拿Long类型的equals方法的源码来看一下具体实现public boolean equals(Object obj) { if (obj instanceof Long) { return value ((Long)obj).longValue(); } return false; }可以看到这类包装类型的比较其实也就是我们上述说的获取具体value值以后再去比较的操作。空指针空指针基本是每个Java开发人员最恶心的异常也是见过最多的异常之一可能出现在各种业务代码和场景中在阿里规范手册中有很多针对空指针的规范和处理如下【强制】Object 的 equals 方法容易抛空指针异常应使用常量或确定有值的对象来调用 equals。【推荐】防止 NPE是程序员的基本修养注意 NPE 产生的场景:返回类型为基本数据类型return 包装数据类型的对象时自动拆箱有可能产生 NPE。反例:public int f () { return Integer 对象} 如果为 null自动解箱抛 NPE。数据库的查询结果可能为 null。集合里的元素即使 isNotEmpty取出的数据元素也可能为 null。远程调用返回对象时一律要求进行空指针判断防止 NPE。对于 Session 中获取的数据建议进行 NPE 检查避免空指针。级联调用 obj.getA ().getB ().getC (); 一连串调用易产生 NPE。可见空指针出现的场景可能会有很多而在开发中一些必要的检查减少空指针是每个程序员都应该有的素质但是有些不规范的操作或者疏忽可能会导致空指针的诞生例如1.服务交互信息不规范的坑一个经典的接口服务交互的场景下往往有时候会将服务中的异常进行try-catch处理返回的是一个固定的result封装实例这种情况下如果内部属性设置不规范很容易在调用方使用返回实例进行操作的时候因为疏忽导致空指针异常。2.返回实例的坑还有一些服务的代码编写过程中部分开发人员有自己的个性写法例如数据库查询某个数据的时候如果查询不出结果集并不是返回null而是创建一个空的实例进行返回这一下可好调用方无论怎么校验空指针都会在使用getxxx方法获取到的属性进行操作的时候报空指针异常除非调用方将内部所有的get返回的结果都去进行一次空指针判断或者根据某几个唯一属性确认实例是否为空等但无论如何操作都无法避免可能存在的大量的空指针。3.自动拆箱装箱的坑在企业开发的过程中往往存在大量的实例转换操作这个时候我们往往是通过工具类进行转换但是有时候我们的实例是存在于两个工程内的往往有时候因为是两个人定义的同样名称的类变量但是类型一个是基础类型一个是包装类型这个时候往往我们下意识会觉得java会自动拆箱装箱所以没关系的肯定会转换过去的再或者基本类型有默认值的肯定不会出现空指针想法很美好但是事实真的如此吗我们看一个例子Datapublic class GoodCreateDTO { private String title; private Long price; private Long count;}Datapublic class GoodCreateParam implements Serializable { private static final long serialVersionUID -560222124628416274L; private String title; private long price; private long count;}这个时候我们潜意识中会认为外部接口的变量都是包装类型或者引用类型所以我们在实现了类似如下的转换代码的时候就容易出现空指针操作public class GoodCreateConverter {public static GoodCreateParam convertToParam(GoodCreateDTO goodCreateDTO) { if (goodCreateDTO null) { return null; } GoodCreateParam goodCreateParam new GoodCreateParam(); //赋值操作 goodCreateParam.setTitle(goodCreateDTO.getTitle()); goodCreateParam.setPrice(goodCreateDTO.getPrice()); goodCreateParam.setCount(goodCreateDTO.getCount()); return goodCreateParam;}}但是如果在传递来的实例中count不是必传参数可能存在null的时候这个时候我们使用getCount操作由于获取的类型是包装类型而我们需要赋值的是基本类型这个时候就会触发自动拆箱装箱null的拆箱就会报空指针异常往期精选CHOICENESS是兄弟就来“kan”我
