在设计一段空安全代码时，更好的方法是什么？
F# 和 Scala 有封装空检查的 Options 类型，但我们也有静态代码分析工具，如代码协定、findbugs。
对我来说，静态分析似乎更干净一些，那么 Option/Maybe 的原因是什么？特别是，是什么让它更好地防止 NullPointerExceptions/NullReferenceExceptions？
问问题
462 次
3 回答
15
Option用于模拟计算可能返回值的事实。它不只是为了封装空检查而存在；许多函数式编程语言，如 SML、Haskell 没有，null但Option/Maybe它们作为建模问题的有用工具存在。
对我来说，静态分析似乎更干净一些，那么 Option/Maybe 的原因是什么？
在函数式编程的上下文中，使用静态分析来检查是否存在值是多余的。静态类型检查可以做得很好（使用Option）。并且类型系统可以保证绝对正确性，而静态分析工具可能会出现误报。
静态分析工具的另一个问题是成本高。构建它们（我不知道任何好的 F# 和 Scala 静态分析工具）和使用它们（软件购买、开发人员培训）的成本很高。诚然，它们很强大，应该用于捕获更细微的错误（静态类型检查器无法捕获），例如索引越界、整数溢出等。
于 2013-01-31T20:49:13.710 回答
11
Option是一元的。一个主要的好处是透明地集成到单子计算链中，通常使用for理解语法。
此外，我怀疑静态分析甚至可以在原则上避免测试是否存在值（Some/None区别）。我的直觉是它相当于停止问题。
于 2013-01-31T20:21:05.157 回答
9
一方面，静态分析只有在 API 被注释或完整的源代码/字节码可用时才能工作。
如果你有一个 API，但实现它的实际库将在运行时决定，静态分析是无能为力的。
另一方面，静态分析本质上是有限的。图灵完整性的限制适用，这意味着它无法决定某些情况是否在所有情况下都可能为空。
所以，这些都是静态分析的限制，不是选项类型共享的，但是选项类型有一个额外的优势：它们是 monad。这意味着您可以使用它们进行计算，而如果仅限于可空性的 if 检查，您将不得不求助于重复自己。
最后一个陈述可能不清楚，但这是事物的本质：如果您了解如何使用 monad，则无需进一步解释；如果你不这样做，那么解释对你没有多大帮助。学习使用 monad 的最好方法是使用它——真的和编程中的其他一切一样。
于 2013-01-31T20:43:23.580 回答