Java开拓者必知：开拓中常见的伤害信号

        【 技能】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行使的是沟通的属性，而且在这两个要领中属性的次序要保持同等。

　　编译器告诫与IDE或器材的告诫、提醒及发明

　　来自于javac编译器的告诫以及IDE和其他代码说明器材的提醒信息是Java中明明的伤害信号。可以这么说，险些每一个告诫与提醒信息都是隐藏的伤害信号。究竟上，我在文中所说起的许多伤害信号都是来自于javac编译器或是其他器材与IDE的告诫或提醒信息。这些告诫与提醒信息不只直接对应于许多Java代码的伤害信号，并且他们一路呈现时更是表白代码呈现了严峻的题目，这必要引起开拓者的足够重视。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!