这就是人们为什么喜欢进行“防错性程序设计”的原因。偏执的习惯有时很有意义，有时则不够清晰也不够聪明，也许当你想到这样写的人的时候还会觉得有点怪异。下面是我列出的的个人感觉最有用而又偏执的 10 项 Java 编程技巧。请看：

　　通过把字符串常量放在比较函数equals（）比较项的左侧来防止偶然的 NullPointerException 从来都不是一个坏主意，就像这样：

　　这是毫无疑问的，把一种表达式转换成另一种更好的表达式，并不会失去什么。只要我们的Options是线中 Optional是对可以为空的对象进行的封装），不是吗？讨论一下

　　Java刚出现的时候，编程一定是件很痛苦的事。那时的API仍然不够成熟，你可能曾经遇到过这样一段代码：

　　“如果抽象径名表示的不是一个目录，那么这个方法返回null。否则返回一个字符串数组，其中每个字符串表示当前目录下的一个文件或目录。”

　　糟糕！前者违反了 Java 编码中 10 个微妙的最佳实践的规则＃5和＃6。因此一定要记得判 null检查！

　　谁知道呢。也许在某个特定场合下他们将会需要另一种 编码值，如果不区分大小写的话，otherString 就会被包含进去此时或许可以返回 -2呢？谁知道呢。

　　毕竟，我们有非常多关于NULL价值亿万美金的错误的讨论。为什么不开始讨论 -1呢，某种意义上来说 -1 是 null 在int类型下的另一种形式。

　　再说一遍。如果你的表达式中有常量，将它放在等式左边。这样当你打算再添加一个 = 时，不容易出错。

　　你可以告诉我任何你想要的开闭原则，不过那都是八道。我不相信你（可以正确继承我的类），也不相信我自己（不会意外地继承我的类）。因此除了接口（专门用于继承）都应该是严格的 final。

　　是的，写成final。如果这样做对你来说没有意义，你也可以通过修改或重写字节码来改变类和方法，或者发送功能请求。作为Java技术栈号小编，我敢肯定的告诉你重写类/方法并不是一个好主意。

　　好吧，我承认，这一条我自己也不常用，虽然我应该用。我希望Java能像Scala语言一样，人们在所有地方都直接用 val 来表示变量，甚至都不考虑易变性，除非明确需要的时候他们才用 var 来声明变量，但是这样的机会特别少。

　　是的，这是会发生的。你觉得你写了一个超好的API，它真的是既酷炫又直观；接着就出现了一群用户，他们只是把一切类型生搬硬套进 Object 中 直到那该死的编译器停止工作，然后他们突然链接到了错误的方法，认为这一切都是你的错（事情总是这样）。

　　Switch作为最滑稽的表达式之一，我不知道是该心存还是默默哭泣。不管怎样，我们既然无法摆脱 switch ，在必要的时候我们最好能够正确使用它，例如：

　　因为在当 value=3 被引入到软件中的时候，deult 就能发挥作用，使其正常运行！别和我提 enum 类型，因为这对 enums 也一样适用。

　　事实上，switch是最坑爹的语句，任何喝醉了或是赌输了的人都可以在某种语言中使用它。看看下面这个例子：

　　在switch语句中，为所有的case都只定义了一个作用域。事实上，这些case不是真正意义上的语句，他们更像是标签，而switch就是指向这些标签的goto语句。事实上，你甚至可以把case语句和 惊人的FORTRAN77项声明 类比，对于FORTRAN，它的神秘已经超越了它的功能。

　　这意味着变量final int j 可以被任何case访问，不论我们是否有break。看起来并不是很直观。我们可以通过添加简单的花括号为每一个case创建一个新的嵌套的作用域，当然不要忘了在每个 case 的语句块最后加 break。

　　编程时的症有时候看起来会很奇怪，会使得代码往往比必需的还要冗长。你可能会想，“啊，这种情况永远不会发生！”，但是正如我所说的，在经历了20年左右的编程生涯后，你不会想要再去修正那些只是因为编程语言的古老和固有缺陷而导致的愚蠢而不必要的bug了。因为你知道。.

　　本文来源于ipfs