用自己的电脑做视频网站吗,wordpress选项框插件,关于计算机网站建设的论文,城阳网站开发在《 Java开发中的常见危险信号》一文中#xff0c;我研究了一些不一定本身就是错误或不正确的做法#xff0c;但它们可能表明存在更大的问题。 这些“红色标记”类似于“代码气味”的概念#xff0c;我在这篇文章中引用的某些特定“红色标记”被称为“代码气味”。 正如我在… 在《 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的替代方法那样有意义时就会发生这种情况。 结论 就像我在第一篇有关Java代码中的红色标志的文章中一样本文中讨论的“红色标志”通常是指在适当和特定的情况下使用时不一定正确的事物但通常确实表明事物不那么正确因为它们可能会在更大的应用程序中使用。 参考来自JCG合作伙伴 Dustin Marx的Java开发中的更多常见 危险信号 来自Inspired by Actual Events博客。 翻译自: https://www.javacodegeeks.com/2013/12/more-common-red-flags-in-java-development.html
