Java开发中更多常见的危险信号

在《 Java开发中的常见危险信号》一文中，我研究了一些不一定本身就是错误或不正确的做法，但它们可能表明存在更大的问题。这些“红色标记”类似于“代码气味”的概念，我在这篇文章中引用的某些特定“红色标记”被称为“代码气味”。正如我在第一篇文章中所述，这些“红色标志”中的几个被认为足够重要，以至于静态代码分析工具和Java IDE会对其进行标记。

直接“记录”消息到stdout或stderr

日志记录框架已经在Java中使用了很长时间，如今，我们拥有各种各样的日志记录框架（其中一些框架是相互构建的），包括传统的Log4j 1.2 ， log4j 2 ， java.util.logging （ Java Logging API ）， Apache Commons Logging和SLF4J 。鉴于此，当我在Java代码中看到System.out和System.err引用时，我感到很惊讶。

有许多原因直接引起人们关注是否存在直接写入标准输出或标准错误的Java代码。引起关注的一个原因是，这可能意味着不成熟的代码，该代码原本打算在以后更改为日志记录，但却没有得到最终的关注。引用标准输出和标准错误的另一个缺点是，“已记录”消息可能不会出现在日志文件中，而其余日志则由日志框架编写。第三个问题是，日志记录框架提供了许多不错的功能，而简单地写入标准输出和标准错误并没有提供这些功能。这些功能包括轻松控制所记录消息的级别的能力，在指定的记录级别下控制是否通过性能降低来生成大型输出字符串的功能，轻松将捕获的异常与已记录的错误消息相关联的功能，并且能够轻松地将输出重定向到不同的目的地和格式。尽管所有这些都可以在直接处理输出和错误流时手动完成，但它需要自定义工作，而不是“开箱即用”。

除了使用System.out和System.err直接访问外，Java代码中还存在一些写入标准输出和标准错误的表现形式（尽管它们通常隐式包含System.out和System.err ）。例如， Throwable.printStackTrace（） [更常用于Exception的处理]，正如其Javadoc所言：“将此throwable及其回溯打印到标准错误流中。”

使用StringBuffer而不是StringBuilder

这诚然是一个很小的事情，但它可以指示过时的 Java代码（ StringBuffer的推出在JDK 1.0和StringBuilder的介绍在J2SE 5 ）或Java代码在开发商没有明白之间的差别的StringBuffer和StringBuilder的。在大多数情况下，两者之间的性能差异对于手头的应用程序并不重要，但是由于StringBuilder在大多数我使用StringBuffer的情况下更可取，因此人们也可能会享受使用StringBuilder通常带来的轻微性能优势。我有困难的时候，回顾一个实例中，我所看到StringBuffer使用其中StringBuilder不可能被替代。一个相关的危险信号是在其构造函数或重载的append方法中将String串联与StringBuilder混合。

方法和构造函数中的参数过多

当方法或构造函数的参数过多时，尤其是在多个参数具有相同类型的情况下，我总是担心其客户端无法正确使用该方法或构造函数。例如，如果一个方法接受三个String和三个boolean ，则客户端很容易混淆传入的特定值。在这种情况下，编译器无济于事，这是检测问题根源的唯一方法（甚至根本不存在问题）在运行时（通过单元测试或其他测试，或者可悲的是，在软件的常规执行过程中）。对于不正确的设计，太多的参数也可能成为“危险信号”。我不会在本文中更深入地讨论这个“红色标志”，因为我已经介绍了这个“红色标志”，多种解决方法，并在一系列八篇博客文章中介绍了它。

Java方法中的参数太多，第1部分：自定义类型
Java方法中的参数太多，第2部分：参数对象
Java方法中的参数太多，第3部分：构建器模式
Java方法中的参数太多，第4部分：重载
Java方法中的参数太多，第5部分：方法命名
Java方法中的参数太多，第6部分：方法返回
Java方法中的参数太多，第7部分：可变状态
Java方法中的参数太多，第8部分：工具

过多的显式投射

显式转换可能是危险信号情况的最佳示例之一，在该情况下，转换本身可能不会影响正常工作的任何功能或逻辑，但是提示情况不尽如人意。强制转换可能意味着较差的设计选择（例如，未正确使用多态性，在不适当的情况下使用继承，或迫使从未设计过的东西放在一起）。在许多情况下（例如，在获取Spring Framework上下文bean时），显式强制转换当然是适当的或必需的，但是显式强制转换也可以用作拐杖，以使未经过精心设计的工作正常进行。强制转换还可以指示过于宽泛的API或过于宽泛的API中使用的接口（在下一项中突出显示）。

接口或类的使用范围太广

当Set或List或更具体的接口更合适时，我经常看到Collection接口用作方法参数或返回类型。例如，一个返回Collection但希望客户端代码知道返回的Collection是有序的方法，应该返回List或更具体的接口或List实现。同样，如果某个方法需要一个有序的Set ，则它应该将该方法宣传为希望有SortedSet或类似的接口或实现类。对于给定的合同，当返回或期望作为参数的接口或类太宽泛时，有人被迫“知道”这种情况，并强制转换为适当的级别以获取他们所依赖的功能。

使用适当的级别或接口或类不仅可以避免不必要的显式转换。适当的类型级别比单纯的文档可以更好地宣传和执行方法合同。但是，它远不止于此。在某些情况下，当公告的接口太宽而无法捕获方法协定中的假设时，可能会发生重大的运行时异常。例如，一个通用接口可以选择支持一个方法，但是该接口的实际实现在被调用时会抛出UnsupportedOperationException ，因为它没有实现该可选方法。在UnsupportedOperationException和ClassCastException之间，使用过宽的接口或类可能会导致潜在的严重运行时问题。

这并不是说应该避免使用接口或广泛的类。而是说，应该在返回类型和参数类型中使用适当的抽象度，以便适当地宣告和强制执行调用双方的预期行为。

使用List.addAll（）

使用重载的List.addAll（）方法之一会让我感到紧张，当我在代码中看到它时，它会亮红色。这并不意味着使用它总是错误的，但是似乎由于滥用它，我似乎已经看到了很多肿的内存问题。因为List会添加开发人员喜欢的“重复”对象，所以错误的代码可以用冗余对象以指数方式填充这些List 。此范围的负面影响从潜在的性能障碍到内存不足。当我看到使用List.addAll() ，我会仔细检查代码并对其进行单元测试，以确保其内存消耗不会失控。如前面的“红色标记”中所述，必须对Collection.addAll()任何使用进行类似于List.addAll()分析，直到可以肯定地知道Collection实际上不是List为止。

非Java方言

也许对我而言，最好的例子是“危险信号”，这是与“普遍接受的Java编码标准 ”相反或有明显不同的惯用语和代码约定的频繁使用。使用名称，大小写或其他样式问题都不会直接影响代码的正确性或性能。但是，这些差异仍然是“危险信号”，警告逻辑或性能方面的潜在实际问题，因为使用这些严重的非标准习语和约定意味着开发人员可能是Java的新手，因此可能犯了一些新的错误。 Java。关于“不带重音”编写Java代码的重要性的好文章是讲不带重音的Java语言。在该文章中，作者Elliotte Rusty Harold撰写了有关如何更难以阅读和维护此类代码的文章。

在相对罕见的情况下，这可能会从样式问题变为影响问题。当人们以一种在另一种语言（例如C或C ++）中最有意义的方式编写Java代码，但没有Java的替代方法那样有意义时，就会发生这种情况。