動態定型語言的支持者認為,靜態定型語言的型態檢查無法抓出所有錯誤,只要有完整的測試,編譯器的型態檢查就是多餘。Joshua Bloch說:「既然寫正確的程式那麼難,我們就應該盡力取得幫助。所以,能減少bug的所有東西都是好的。這就是我是靜態型別語言和靜態分析的信徒的原因。」

誰來保證型態的正確性?

動態定型與靜態定型語言從古至今持續存在爭戰,雙方支持者所持理由各不相同,爭論可從語言的簡潔、彈性、文件化、執行速度、靜態分析、重構工具等各方面切入,無論是站在哪一方,最終無論支持動態定型或靜態定型,都得回到程式撰寫的最基本要求:「程式碼本身必須正確」。程式碼中用來進行運算的各種值,它們各自應當是何種型態,也是程式碼本身的意圖之一,程式碼本身必須正確,自然也包括了型態必須正確這件事,那麼誰來保證型態的正確性?

靜態定型的支持者認為,既然程式中有許多型態上的錯誤,會讓程式碼在執行時發生錯誤,為何不在編譯時期就找出這類型態錯誤,讓維護工作變得輕鬆?

畢竟開發者總是以為他們知道自己在操作什麼型態,實際上並不是如此,更多時候是漫不經心、未仔細思考正在操作的值其型態為何,Java中如影隨形的ClassNotFoundException錯誤,經常就是這麼來的,某些程度上NullPointerException也是型態錯誤,因為null可以做為任何型態的值,若能使用JDK8中Optional這類Typesafe Null型態,編譯時期就有機會找出這類錯誤。

然而,動態語言的支持者對此不以為然,他們認為靜態定型語言沒有辦法抓出所有的型態錯誤,甚至開發者也有辦法編譯器忽略型態錯誤,像是使用轉型(CAST)語法或自行加註了錯的型態,而且就算編譯器能抓出所有型態錯誤,也不代表程式的邏輯正確,既然最後無論是型態或是程式邏輯,都得執行單元測試來確保正確性,就沒有依賴靜態定型進行型態檢查的必要性。

靜態定型無法抓出所有型態錯誤是事實,型態正確不代表程式邏輯正確也是事實,只是在為此而擁抱動態語言之前,開發者是否思考過要操作的值實際型態是什麼?單元測試如何確保程式中操作的值具有正確型態?開發者在型態上的單元測試有足夠的覆蓋率嗎?對於型態的正確性,你是依賴自己,還是依賴工具?

重新思考型態是什麼?

任何數值都是記憶體中的一組位元,型態賦予這組位元意義,這樣開發者就能得知如何對待這組位元,因此型態也部份解釋了開發者想要程式做哪些事情。多數開發者很少認真思考型態是什麼,多半存在「2是個整數」、「"Hello World"是個字串」、「[1, 2, 3]是個List」這類模糊的認知,實際上型態代表值具有彼此相關的特性,這些值因為具有同一組操作與行為,而被歸在同一個型態集合。

在Haskell語言中,一開始就要開發者思考型態是什麼,在使用data定義一個型態時,得指定值建構式(Value Constructor),也就是得思考型態可能包括的值以及如何建構,或者是如何以型態作為參數產生新的型態(例如Maybe型態),如果你要對定義的型態進行運算,還得進一步思考型態應衍生自哪個或自行定義Typeclasses,這樣要運算的值,才能有對應的操作與行為。

函式本身也有型態,以Haskell為例,取List首項元素的head函式,其型態是[a] -> a,也就是給一個包括a型態的List,head函式要傳回a型態,雖然在Haskell中可藉由型態推斷(Type inference),使得定義函式時不用宣告函式型態,不過明確地宣告型態是個好習慣,這可以讓你多思考一次(日後也容易閱讀與瞭解)函式的意圖。在不存在一級(First class)函式的語言之中,函式本身也可視為有隱含的型態,也就是函式的參數與傳回型態。

在Haskell這極度重視型態正確性的靜態定型語言中,經常會發現的事情就是,即使開發者本身自認為程式碼中已經沒有型態錯誤的問題,在編譯器回報的錯誤訊息中總有辦法發現,自己正試圖在某些地方犯下型態不正確的蠢事,問題往往不是呼叫函式時傳入或傳回型態正確與否這麼簡單,而往往是發生在函式中試圖進行某操作時,該值的型態並沒有對應的行為(而你以為有),這說明了開發者對型態的思考總是不足的。

單元測試要對型態做哪些測試?

在開始認真思考型態是什麼,以及靜態定型語言中編譯器作了哪些型態檢查之後,再從測試的角度來看,就可發現,靜態定型本質上是對型態進行大量且廣泛的斷言測試,也就是函式要能接受特定型態的輸入,在函式中進行型態定義的操作,且最後要有特定型態的傳回值,如果違反了其中任何一項,就相當於斷言測試失敗,只是這(大多數的)斷言測試是在程式執行之前,由編譯器來執行,因而開發者在執行時期,可以只對函式實施特定輸入應有的輸出之單元測試,或者較少量的型態測試。

在使用動態定型語言之時,由於沒有編譯器來對型態執行大量且廣泛的斷言測試,擔子就落到了開發者身上,不過,這也給了開發者在型態檢查上的彈性。

舉例來說,如果設計一個add_two函式,靜態定型語言要求定義參數與傳回型態,如果參數是int,那麼開發者就不能直接用float來呼叫add_two函式,還得另外設計一個接受float的add_two函式,而實際需求可能只是要對參數加2後傳回而已,這就是有些動態定型支持者覺得,靜態定型語言對型態檢查的堅持是沒有必要的;動態定型語言中,可以只設計一個add_two函式,如果程式中真的在乎傳回型態,那只要針對傳回型態做斷言就可以了,如果程式中真的在乎參數型態,那麼測試就是要確定傳入型態不符時,函式會拋出型態不符的例外。

單元測試在動態語言中,可以分為兩個部份來看:一個是對特定輸入應有特定輸出之測試,一個是對於特定型態輸入應有特定型態輸出之測試。只是對於後者,在靜態定型語言中,可以輕鬆擁有(然而犧牲了彈性)。

「只要有全面的單元測試就不需要型態檢查」也是個迷思,問題在於很難有全面的單元測試,無論理由是來自於開發者本身的觀念、能力,或者是專案政治性因素,如果開發者使用動態定型語言,卻發現到需要許多單元測試來執行型態檢查,而又無法做得全面時,藉助靜態分析工具,透過其規範的型態加註方式,執行類似編譯器的型態檢查工作,就是必要的。

你瞭解型態檢查的需求嗎?

靜態定型無法抓出所有型態錯誤是既定的事實,單元測試是必要的,只是在持有這個理由投入動態定型語言之餘,也得多想一下,你有撰寫測試的習慣嗎?在投入動態定型語言之後,是否願意多寫些測試,以彌補沒有編譯器協助型態斷言測試的這個事實嗎?或者是,你有能力撰寫出夠完整的單元測試,來檢測出大多數的型態錯誤嗎?

現實開發在型態檢查這部份,靜態定型檢查無法取代單元測試,單元測試其實也無法取代靜態定型檢查,無論選擇動態或靜態定型語言,或許都得更進一步地問,你瞭解程式語言中的型態系統嗎?你是否瞭解開發上對型態檢查的需求嗎?如此才能瞭解如何善用選定語言在型態檢查上的優勢、彈性,或在必要時選擇其他方案,以補其不足。

作者簡介


Advertisement

更多 iThome相關內容