在現在數位相機當道的年代,不知道還有多少人曾經看過以前某個底片廣告,還記得那句經典台詞「拍誰像誰,誰拍誰誰都得像誰」,對於程式設計來說,從第二種語言的使用開始,也經常會面對類似的問題,對認真負責的開發者來說,總會想寫出符合該語言原汁原味的程式,避免明明用A語言寫卻看起來像是B語言的調調。

Java寫的像C?

在過去Java如日中天的年代,印象中最常看到的類似抱怨是「把Java寫得像C」,這特別是指撰寫Java時,是否善用了Java物件導向風格,還是把一個又一個的靜態方法當作函式來使用,早期的文件甚至書籍甚至也會有這種情況,因為Java是C-like的語言,語法與關鍵字有許多重疊之處,許多開發者或作者就只是將一些關鍵字換一下,就開始將C一對一地「翻譯」為Java程式。

語法與關鍵字相近的語言,似乎特別容易有這類問題,記得朋友曾經說過:「在一個C#的專案中,雖然你不知道程式碼經手過哪些人維護,但是經常很容易就能看出,哪個部份是曾經熟悉Java的開發者寫的,哪個部份是一開始就使用C#的人寫的。」在JavaScript剛開始鹹魚翻身的年代,也有許多人試著將之與Java相比,甚至特意寫的像Java,忽略了JavaScript本身具有一級函式、基於原型(prototype-based)的特性等。

或許是不少開發者看過多次類似的情況了,在打算使用另一門語言開發程式時,開始會重視起語言的原汁原味這回事,像是最近收到的一個課程邀請中,就有著「請老師增加C++跟Python寫作風格差異跟一些慣例,避免我們寫Python看起來像寫C++」這樣的需求。由於看太多「Java寫的像C」的案例,在我學習其他程式語言的時候,也時時在留意著該語言的風格典範、語言慣例、語法特性等,而最近在撰寫Python程式語言紙本書時,也更時時考量著,寫出來的範例是不是夠Pythonic!

為什麼要追求Pythonic?

由於Python是個風格鮮明,且特別強調Pythonic,也是目前我僅見特別有此一形容詞的語言,想要知道「為什麼寫A不能像B?」、「為什麼要追求語言的原汁原味?」等的答案,搜尋一下Pythonic這個關鍵字,其實就可以得到不少的闡述與討論,將Pythonic這形容詞拿掉,多半也就是其他語言也能適用的答案。

一門語言從出現到成長到累積足夠的使用者,這中間會累積越來越多的使用經驗,也就會有許多關於語言如何正確使用,如何讓語言能具有可讀性、易維護、正確且執行效率高的慣用法,在一門語言演進而打算加入新特性時,經常也將這些慣用法納入考量,甫出爐不久的ECMAScript 6就是個具體實例,當中不少新語法都是基於既有的慣用法而來。

慣用法的累積與語言的納入演化是交相迭代的,因此就算語言彼此之間語法的再相近,慣用法往往都無法直接從另一門語言移植過來,若真有人這麼做,那部份的程式碼跟既有的專案就會出現格格不入的感覺,可能看來不易閱讀,也許多餘而冗長,甚至影響了元件間彼此的整合,或者應用程式整體的執行效率。

不過,為了追求語言的慣用法,一開始就將兩門語言之間的語法、排版風格等逐條列出,對我來說其實是件極其無趣且沒意義之事,某些程度上我甚至覺得,這就跟逐條列出Python 2與Python 3之間的差異性,一樣的無聊。瞭解一門語言的慣用法對我來說,從來就不是這樣透過逐條比較而來。

吸收語言的慣用法

語言的慣用法,大致上可以分為兩個面向來看待,一是命名與排版,二是語言特性。對於前者,其實現代程式語言,多半會有份官方文件,整理了語言慣用的命名方式,或者是排版風格。像是Python的PEP 8就是個例子,若官方沒有列出,社群間多半也會有類似文件,甚至不同公司或團隊也會有自己的一套規範,像Google就會有自己的〈Google Java Style〉,或〈Google Python Style Guide〉

這說明了,除了考量語言本身的命名方式或排版風格之外,若團隊開發時有需要,也可以基於既有的命名與排版慣用方式,制定一套適用的規範。此時,若有工具輔助更好,就像Python的強制縮排是一個例子;Go語言認為這個問題太複雜,本身就提供gofmt來協助格式化是個很棒的主意──不少整合開發工具在編輯器上,都有可自訂的排版功能,而像JavaScipt也有JSLint這類工具,可以善加利用。

是否善用語言特性這點就比較麻煩,就結論來說,方式之一就是透過大量原始碼的閱讀來培養。那麼到哪去閱讀原始碼?官方的標準程式庫原始碼是絕佳的好地方,舉例來說,在實作Python物件的__eq__()方法時,我曾經試著遵循著Java的實作方式,在Python中使用isinstance()來判斷物件型態,然而在閱讀標準程式碼原始碼中就發現,多數情況下並不使用isinstance(),而只是使用hasattr()來判斷物件是否具有相關屬性,我才想起Python是門動態語言,而動態語言多數情況下只需考慮行為而非型態的慣例。

另一個吸收慣用法的來源,就是API官方說明文件,像是Python的標準程式庫說明文件就提供了大量範例,如果願意細心閱讀,可以發現不少的語言的特性與技巧。

例如,Python建議的檔案讀取風格:讀取一個檔案最好的方式,就是不要去read!因而常見的慣用法就是使用for in來迭代檔案物件,然而,若想讀取文字檔案內容,並將每一行安插入set。官方文件中就談到的一個簡潔方式,是將檔案物件直接傳給set:

unrepeated_lines = None
with open('filename', 'r') as f:
    unrepeated_line = set(f)

想要善用語言特性的方式之二,其實與是否願意持續重構程式碼有關,就這點來說,一名開發者可以一直將Java寫的像C,絲毫沒有用到任何物件導向的特性,若不是他撰寫的程式碼,完全嗅不出任何的餿味(Bad smell),或者是程式中的資料,從來就不曾與某組操作發生過密切關聯的話,那多半就表示這名開發者不在意也不會去檢視程式碼的品質,更別說運用重構手法來善用語言特性,以便改進程式可讀性、維護性,甚至是效率了。

是否願意持續改進程式碼?

如果已經熟悉一門語言,在試著運用另一門語言的同時,運用已熟悉語言的經驗,其實是件很正常的事情,這讓過去我們一些有用的作法得以延續,以便保證目前撰寫的程式能夠運作,此時,寫A卻像B並不是太大的問題,當然,若想在程式開發的一開始,不讓寫A卻像B的情況太嚴重,那麼整個團隊成員對語言有一定程度的瞭解,事先適當地制定規範會是必要的。

在這樣的前提下,剩下的就是團隊或成員,對於程式碼品質是否在意?是否願意持續重構程式碼有關了!隨著對一門語言運用的經驗越多,看到的文件與原始碼越多,必然會發現更多適合的作法,可以改進過去撰寫過的程式碼,若團隊或成員能夠有意願與時間(或者被允許)進行重構,那麼會比一開始,就試圖條列兩門語言的寫作風格差異跟一些慣例,來得有意義且更能擁有具體成效!

作者簡介


Advertisement

更多 iThome相關內容