良好编程风格的技巧

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

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

我认为值得注意的几件事：

getter / setter方法

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

person.getName();
  person.getAddress();
  person.getMobileNumber(); 

  person.name();
  person.address();
  person.mobileNumber();

常量命名约定

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

局部变量的最终关键字

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

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

异常后缀

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

• 异常的定义–某些东西扩展了异常
• 引发异常–引发新事物
• 抛出异常的声明–抛出异常
• 捕获异常– catch（某事）

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

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

这篇文章最初出现在CodeJargon上

翻译自: https://jaxenter.com/good-programming-style-114969.html