当我们有代码契约/静态分析时，为什么我们需要Option类型？

Question

在设计零安全代码时，有什么更好的方法？

F＃和Scala具有封装null check的Options类型，但我们也有代码契约，findbugs等静态代码分析工具。

对我来说静态分析看起来有点干净，那么Option / Maybe的原因是什么？特别是，什么能更好地防止NullPointerExceptions / NullReferenceExceptions？

Answer 1

Option用于模拟计算可能返回值的事实。仅仅为了封装空检查不存在;许多函数式编程语言（如SML，Haskell）没有null但Option/Maybe作为建模问题的有用工具。

  

对我来说，静态分析看起来有点干净，那么Option / Maybe的原因是什么？

在函数式编程的上下文中，使用静态分析来检查缺少值 overkill 。静态类型检查可以很好地完成（使用Option）。类型系统可以保证绝对正确，而静态分析工具可能有误报。

静态分析工具的另一个问题是高成本。构建它们需要花费很多（我不知道任何适用于F＃和Scala的静态分析工具）并使用它们（软件购买，开发人员培训）。不可否认，它们很强大，应该用于捕获更微妙的错误（静态类型检查器无法捕获），例如索引越界，整数溢出等。

Answer 2

Option是monadic。主要好处是透明地集成到monadic计算链中，通常使用for理解语法。

此外，我怀疑静态分析甚至可以原则上避免测试是否存在值（Some / None区别）。反正我的直觉是它等同于停止问题。

Answer 3

首先，静态分析只有在API被注释或完整源/字节码可用时才能工作。

如果你有一个API，但实现它的实际库将在运行时决定，静态分析是无助的。

另一方面，静态分析本质上是有限的。图灵完整性的局限性适用，这意味着它无法在所有情况下决定某些事物是否为空。

因此，这些都是静态分析的所有限制，不是由选项类型共享，但选项类型还有一个额外的优点：它们是monad。这意味着您可以使用它们进行计算，而如果仅限于检查可空性，则必须重复自己。

最后的陈述可能不清楚，但这是事情的本质：如果你了解如何使用monad，你不需要进一步的解释;如果你不这样做，那么解释对你没有多大帮助。学习monad用法的最好方法是使用它 - 与编程中的其他内容一样，真的。