良好编程风格的技巧

是否曾经浏览过别人的代码，然后对自己说：“该死，这位程序员有风格……”？我们不是在谈论CSS，而是约定，方法和简洁代码的完美结合。

在编写清晰易读的代码时，样式具有重要作用。遵守约定和最佳做法是一个很好的起点。除此之外，还有大量的选择余地。这些很大程度上取决于开发人员的级别和个人喜好。

约定和最佳实践存在非常特殊的危险。他们中的大多数都是从该行业中摘录的经验，并且有充分的理由在那里。其中一些可能令人怀疑，但很少（如果曾经有过）受到质疑。它们被并入了编码风格，并且没有意识地指出它们变得不可见。我认为所有开发人员都应不时调查其代码，并检查此类问题的最琐碎元素。

我认为有几件事值得研究：

getter / setter方法

因为IDE可以很容易地生成它们，所以它们经常被滥用。一些开发人员习惯于立即生成它们，而无需进一步思考就丢弃了面向对象编程的最重要元素-封装。变量是在可能不可变的对象上创建的。该get...()前缀是没有意义的，实际上损害可读性：

person.getName(); person.getAddress(); person.getMobileNumber();    person.name(); person.address(); person.mobileNumber();

常量命名约定

惯例是使用大写的名称，这可能非常难以理解–特别是在类中有许多长名称常量的情况下。除非它是api的一部分，否则字段是常量的事实是实现细节。

局部变量的最终关键字

如果局部变量未分配为最终变量，则某些静态代码分析工具会显示警告-如果它们仅被分配了一次。尽管它在某些特定情况下会增加价值，但如果无故将其应用于所有局部变量，它带来的混乱可能会使代码难以阅读。

可以说，在长而复杂的方法中严格使用它们是好的，那么问题首先就是复杂的方法。

异常后缀

这确实是一个有争议的问题，但我认为至少值得考虑一下。几乎所有例外...Exception的名称中都有后缀。实际上，这实际上不是必需的，并且确实会增加一些噪音。请注意，在任何情况下，我们遇到异常时，语法都已经很明显：

• 异常的定义–某些东西扩展了异常

• 引发异常–引发新事物

• 抛出异常的声明–抛出异常

• 捕获异常– catch（某事）

删除后缀可以处理被称为事件的异常，而不仅仅是简单的名词–就其本身而言，这是一种有用的做法。比较FileNotFound与FileNotFoundException。在整个代码库中，基于事件的名称和缺少后缀的应用都会产生很好的效果。一些库可以做到这一点，例如javassist，bouncycastle。

这些只是一些特定的示例，重要的部分是注意我们只是自动执行的操作，并意识到我们这样做的原因，以确保它们确实有意义。