Dustin Marx是一位专业软件开发者，从业已经有17年的时间，他拥有电子工程学士学位，还是一位MBA。Dustin维护着一个博客，专门介绍软件开发的各个主题。近日，他撰文谈到了Java开发中常见的危险信号，提出了在日常的Java开发中我们需要尽力避免的一些不正确的做法。 经过多年的开发、阅读、回顾并维护了数万行的Java代码后，我经常会看到Java代码中出现的某些“危险信号”，这些信号经常（但也许并不总是）暗示着代码出现了某些问题。我这里所要谈的并不是那些总是错误的实践，而是想要谈谈在某些场景下可能是恰当，但通常却会导致问题的一些实践。这些“危险信号”有时可能并没有问题，但却会造成问题的积累，并最终导致问题的产生。这里我总结出了一些“危险信号”，并且谈谈在哪些情况下他们是没有问题的，在哪些情况下则会导致问题。 这里将要谈及的很多“危险信号”通常都会收到来自于FindBugs等代码分析工具所发出的警告信息，流行的Java IDE也会将它们标记出来。不过，我发现有不少开发者会忽略掉这些来自于工具与IDE的警告信息，要么是因为他们关掉了提示信息，要么是出于自身的开发习惯或是不理解与这些警告信息所关联的风险，因此会忽略掉警告信息。 对引用使用==（而不是.equals） 很多Java开发者都知道使用==比较原生类型数据，使用.equals比较引用类型数据。这是一条很容易记住的简单原则，Java开发者这么用也没什么问题。有时使用==来比较标准的Java类型引用（String、Integer、Long等等）也没问题，不过这要取决于被缓存的值的大小，因此这么做并不是一个好的做法。有时，我们需要检查标识的相等性而不是内容的相等性，在这种情况下使用==来比较引用就很适合了。相对而言，我更喜欢Groovy的处理方式，==类似于.equals，而===则是更加严格地比较标识。同理，使用!=来比较两个引用也是一个“危险信号”，因为如果待比较的两个对象不共享相同的标识（内存地址），即便他们拥有相同的内容也总是会返回true。 对枚举使用.equals（而不是==） 坦率地说，对于枚举，Java开发者使用==还是.equals都没有太大关系。不过，我更倾向于对枚举使用==。这么做最重要的原因就是对枚举使用==可以防止不小心将枚举与不相关的对象进行比较（永远不会相等）。Object.equals(Object)方法可以接收任意对象，这意味着编译器并不会强制限定传进来的对象要与被比较的对象是相同的类型。一般来说，我更喜欢静态的编译期问题检测而非动态运行期的问题检测，对枚举使用==可以满足这个要求。同理，在比较枚举时，!=与!.equals也是一样的。 魔数与字符串字面值 我经常会在Java代码中看到有人使用“魔数”和字符串字面值。他们对于未来的维护来说是一种“危险信号”，让我十分怀疑应用的正确性。在单个位置处将其标识为常量（如果可能用枚举来表示更佳），这么做可以改善未来的维护，并且让我可以更加自信地相信使用这些值的所有代码都在使用着相同的值。除此之外，在一个地方定义好常量与枚举可以更方便地使用IDE的“查找使用”特性来找到所有使用这些常量的地方。 字符串常量 在看到有限的相关字符串常量时，我就在想使用枚举应该更加适合。对于高度内聚的字符串常量的情况来说更是如此，因为枚举可以更好地表达出这些字符串所表示的概念。相比于字符串常量来说，枚举提供了编译期的静态类型安全与潜在的性能优势。对于程序的正确性来说，编译期的安全是最吸引我的地方。 使用Java的“goto” 很少有人会使用标签代码，如果使用了那也说明用法不当。换句话说，如果使用了也是滥用而已。在大多数情况下，使用Java的“goto”会造成代码的可读性极差。 根据作用域来确定恰当的变量引用 我认为这种方式永远都是不恰当的，但它却能运行，甚至有时是被某些Java开发者有意而为之。比如说，Java开发者将传递进方法的变量在方法执行时指向了另一个引用。该变量（临时指向方法参数）指向了另一个引用，直到方法结束为止，这时它脱离了作用域。在这种情况下，在方法签名的参数定义前加上final关键字会导致编译器错误，这也是我喜欢在方法参数前加上final的原因之一。对于我来说，在方法中声明一个新的局部变量是更加清晰且可读的方式，因为它只能在方法中使用。更为重要的是，作为代码的读者，我不知道是开发者有意希望该参数名只是指向一个不同的值还是引入了Bug，因为将参数重新指向新的引用实际上会改变调用端的值。如果我看到有人这么写，那么我就会找代码的编写者或是通过单元测试来验证代码的意图。 equals(Object)与hashCode()方法的不匹配 虽然我认为每个Java类都应该重写toString()方法，但对于equals(Object)与hashCode()方法来说却并不这么认为。我觉得只有在需要这些方法的场合下才应该重写类中的这两个方法，因为他们的存在暗示着其设计与开发某种程度上的完全改变。特别地，equals与hashCode方法要能满足其意图与契约（位于Object类的API文档），并且需要保持一致。大多数IDE与分析工具都会在其中一个方法重写而另一个没有重写的情况下给出提示。然而，我要确保equals与hashCode使用的是相同的属性，并且在这两个方法中属性的顺序要保持一致.更多内容请关注51testing软件测试网
Dustin Marx是一位专业软件开发者，从业已经有17年的时间，他拥有电子工程学士学位，还是一位MBA。Dustin维护着一个博客，专门介绍软件开发的各个主题。近日，他撰文谈到了Java开发中常见的危险信号，提出了在日常的Java开发中我们需要尽力避免的一些不正确的做法。 经过多年的开发、阅读、回顾并维护了数万行的Java代码后，我经常会看到Java代码中出现的某些“危险信号”，这些信号经常（但也许并不总是）暗示着代码出现了某些问题。我这里所要谈的并不是那些总是错误的实践，而是想要谈谈在某些场景下可能是恰当，但通常却会导致问题的一些实践。这些“危险信号”有时可能并没有问题，但却会造成问题的积累，并最终导致问题的产生。这里我总结出了一些“危险信号”，并且谈谈在哪些情况下他们是没有问题的，在哪些情况下则会导致问题。 这里将要谈及的很多“危险信号”通常都会收到来自于FindBugs等代码分析工具所发出的警告信息，流行的Java IDE也会将它们标记出来。不过，我发现有不少开发者会忽略掉这些来自于工具与IDE的警告信息，要么是因为他们关掉了提示信息，要么是出于自身的开发习惯或是不理解与这些警告信息所关联的风险，因此会忽略掉警告信息。 对引用使用==（而不是.equals） 很多Java开发者都知道使用==比较原生类型数据，使用.equals比较引用类型数据。这是一条很容易记住的简单原则，Java开发者这么用也没什么问题。有时使用==来比较标准的Java类型引用（String、Integer、Long等等）也没问题，不过这要取决于被缓存的值的大小，因此这么做并不是一个好的做法。有时，我们需要检查标识的相等性而不是内容的相等性，在这种情况下使用==来比较引用就很适合了。相对而言，我更喜欢Groovy的处理方式，==类似于.equals，而===则是更加严格地比较标识。同理，使用!=来比较两个引用也是一个“危险信号”，因为如果待比较的两个对象不共享相同的标识（内存地址），即便他们拥有相同的内容也总是会返回true。 对枚举使用.equals（而不是==） 坦率地说，对于枚举，Java开发者使用==还是.equals都没有太大关系。不过，我更倾向于对枚举使用==。这么做最重要的原因就是对枚举使用==可以防止不小心将枚举与不相关的对象进行比较（永远不会相等）。Object.equals(Object)方法可以接收任意对象，这意味着编译器并不会强制限定传进来的对象要与被比较的对象是相同的类型。一般来说，我更喜欢静态的编译期问题检测而非动态运行期的问题检测，对枚举使用==可以满足这个要求。同理，在比较枚举时，!=与!.equals也是一样的。 魔数与字符串字面值 我经常会在Java代码中看到有人使用“魔数”和字符串字面值。他们对于未来的维护来说是一种“危险信号”，让我十分怀疑应用的正确性。在单个位置处将其标识为常量（如果可能用枚举来表示更佳），这么做可以改善未来的维护，并且让我可以更加自信地相信使用这些值的所有代码都在使用着相同的值。除此之外，在一个地方定义好常量与枚举可以更方便地使用IDE的“查找使用”特性来找到所有使用这些常量的地方。 字符串常量 在看到有限的相关字符串常量时，我就在想使用枚举应该更加适合。对于高度内聚的字符串常量的情况来说更是如此，因为枚举可以更好地表达出这些字符串所表示的概念。相比于字符串常量来说，枚举提供了编译期的静态类型安全与潜在的性能优势。对于程序的正确性来说，编译期的安全是最吸引我的地方。 使用Java的“goto” 很少有人会使用标签代码，如果使用了那也说明用法不当。换句话说，如果使用了也是滥用而已。在大多数情况下，使用Java的“goto”会造成代码的可读性极差。 根据作用域来确定恰当的变量引用 我认为这种方式永远都是不恰当的，但它却能运行，甚至有时是被某些Java开发者有意而为之。比如说，Java开发者将传递进方法的变量在方法执行时指向了另一个引用。该变量（临时指向方法参数）指向了另一个引用，直到方法结束为止，这时它脱离了作用域。在这种情况下，在方法签名的参数定义前加上final关键字会导致编译器错误，这也是我喜欢在方法参数前加上final的原因之一。对于我来说，在方法中声明一个新的局部变量是更加清晰且可读的方式，因为它只能在方法中使用。更为重要的是，作为代码的读者，我不知道是开发者有意希望该参数名只是指向一个不同的值还是引入了Bug，因为将参数重新指向新的引用实际上会改变调用端的值。如果我看到有人这么写，那么我就会找代码的编写者或是通过单元测试来验证代码的意图。 equals(Object)与hashCode()方法的不匹配 虽然我认为每个Java类都应该重写toString()方法，但对于equals(Object)与hashCode()方法来说却并不这么认为。我觉得只有在需要这些方法的场合下才应该重写类中的这两个方法，因为他们的存在暗示着其设计与开发某种程度上的完全改变。特别地，equals与hashCode方法要能满足其意图与契约（位于Object类的API文档），并且需要保持一致。大多数IDE与分析工具都会在其中一个方法重写而另一个没有重写的情况下给出提示。然而，我要确保equals与hashCode使用的是相同的属性，并且在这两个方法中属性的顺序要保持一致.更多内容请关注51testing软件测试网