當我們有代碼契約/靜態分析時，為什么我們需要Option類型？

Question

在設計零安全代碼時，更好的方法是什么？

F＃和Scala具有封裝null檢查的Options類型，但我們也有代碼契約，findbugs等靜態代碼分析工具。

對我來說，靜態分析看起來有點清晰，那么Option / Maybe的原因是什么？ 特別是，什么使它更好地防止NullPointerExceptions / NullReferenceExceptions？

Answer 1

Option用於模擬計算可能返回值的事實。 僅僅為了封裝空檢查不存在; 許多函數式編程語言（如SML，Haskell）都沒有null但Option/Maybe作為建模問題的有用工具。

對我來說，靜態分析看起來有點清晰，那么Option / Maybe的原因是什么？

在函數式編程的上下文中，使用靜態分析來檢查缺少值是否過度 。 靜態類型檢查可以做得很好（使用Option ）。 類型系統可以保證絕對正確，而靜態分析工具可能有誤報。

靜態分析工具的另一個問題是成本高 。 構建它們需要花費很多（我不知道任何適用於F＃和Scala的靜態分析工具）並使用它們（軟件購買，開發人員培訓）。 不可否認，它們很強大，應該用於捕獲更微妙的錯誤（靜態類型檢查器無法捕獲），例如索引越界，整數溢出等。

Answer 2

Option是monadic。 主要好處是透明地集成到monadic計算鏈中，通常使用for comprehension語法。

此外，我懷疑靜態分析甚至可以原則上避免測試是否存在值（ Some / None區別）。 反正我的直覺是它等同於停止問題。

Answer 3

首先，靜態分析只有在API被注釋或完整源/字節碼可用時才能工作。

如果你有一個API，但實現它的實際庫將在運行時決定，靜態分析是無能為力的。

另一方面，靜態分析本質上是有限的。 圖靈完整性的局限性適用，這意味着它無法在所有情況下決定某些東西是否為空。

因此，這些都是靜態分析的所有限制，不是由選項類型共享，但選項類型還有一個額外的優點：它們是monad。 這意味着您可以使用它們進行計算，而如果僅限於檢查可空性，則必須重復自己。

最后的陳述可能不清楚，但這是事情的本質：如果你了解如何使用monad，你不需要進一步的解釋; 如果你不這樣做，那么解釋對你沒有多大幫助。 學習monad用法的最好方法是使用它 - 就像編程中的其他所有東西一樣。