Coding Style閒聊


偶然聊天聊到Coding Style,突然想寫些東西。

Coding Style要直譯的話,也許可以翻譯為程式風格? 但其實這是一個不容易解釋的東西。之前的某工作碰到Coding Style這個東西之後,不自覺開始去研究,才發覺就兩個word,卻包含了太多太多的學問。

將其視為程式風格,應該是最一般的認知。可以去規範Naming Rule,可以去規範coding時的一些一致性要求如縮排之類,以增強可讀性,甚至詳盡到規範coding時勿犯的錯誤…那問題就來了。

問題1:Coding Style這東西是軟體開發時必要的嗎?

相信對軟體業始終要死不活的台灣來說,一定很多老闆會覺得,東西「能動就好啦」,誰去管你怎麼寫的? 但很弔詭的是,在我的認知裡,Coding Style這東西反而是為老闆而準備的。

如果我只是在寫自己的程式,如果全公司只有我一個programmer,根本不用去顧慮一致性這種東西。對頂尖的programmer來說 (不是我) ,要求他們的程式有可讀性,可能反而是扼殺他們天馬行空的想像力。但偏偏現實通常不是這樣的,只要是與人合作coding,只要這軟體將來成為產品需要有人維護,只是將來公司還想繼續賣這個產品…可讀性便成為了一個baseline,也許這也算是軟體工業化的初步概念,是軟體品質要求的第一步。

問題2. Coding Style對programmer有意義嗎?

前面說到Coding Style可以增強可讀性,使整套原始碼易於維護。但對programmer來說,Coding Style有意義嗎?

我認為是有的,這可以分兩個層面來看,維護Coding Style的programmer與一般programmer。

想當然爾,能制訂一套Coding Style出來的人,必然是programmer,而且是對整體需求有一定了解,自己也有一定水準的programmer。而且在制訂的過程中,也會經由不斷的取捨、調整、深究技術內涵的過程中獲益良多。而這種過程也可能不是單向的,一般的programmer也可以基於自身的了解回饋之,與維護者就某議題深入討論,使一套Coding Style更加完備。

就算只是遵循現成的Coding Style,一般的programmer都可以從中挖掘出以前可能未曾深究的問題─好吧,我承認我就是因為這樣,會喜歡去看Google C++ Style Guide之類的東西─不僅僅只是follow而已,一份面面俱到的Coding Style,其實包含了很多的技術性思考成果,從中可以了解人家可能使用了哪些技術,為什麼要這麼規範,以避免就像以前一樣,寫出可能有潛在錯誤的code…

Coding Style可以精進技術,傻嗎? 或許吧,我想我一直很傻。

問題3:Coding Style的範圍到底多廣?

就之前的經驗來說,Naming Rule的規範,coding時的一致性風格,甚至也有人條列coding的建議或應避免的潛在問題─以C++而言,Effective C++這系列名著的內容,「部份」就可能在Coding Style裡出現─

麻煩就在於「部份」這種不精確的詞彙。難道Coding Style是這麼的不嚴謹?

在我的認知裡,是的,並沒有一套一體適用的Coding Style。隨著程式語言的不同,公司產品及專案性質的差異,Coding Style都應該因地制宜、因時制宜而有所調整。

程式語言的差異比較容易理解,如果語法不同,自然會造就不同的coding style。但其它呢? 舉個例子好了,C/C++裡的Null Pointer Check,在我一開始接觸Coding Style時,被教導的是函式參數 (function parameter) 如果有pointer,函式的進入點就應該要做Null Pointer Check。

可是寫了一段時間之後,一方面是需要去整理一些亂七八糟的code,改著改著慢慢就產生了疑惑─檢查函式引數 (function argument) 是合理的,畢竟有問題的輸入需要處理或排除;但每一次檢查都是一個運算,是不是真的有必要在每一個函式進入點都檢查null pointer? 後來也確實看到提倡減少這類檢查的說法,所以有另外一個觀念是,如果此函式僅會被內部呼叫,傳入的是較為安全的引數,可以不做Null Pointer Check以減少運算。

但這代表我一開始被教導的觀念錯了嗎? 也許不盡然,如果負責撰寫的是API之類的函式,因為無法期待外部傳入引數的正確性,所以檢查也是合理的,對吧? 那這兩種觀念是否有所牴觸而令人無所適從呢?

我想,取決於不同的時空背景,需要不同的處理方式,這就是說Coding Style難以一體適用的原因,隨著產品及專案、負責內容的不同,需要去調整Coding Style的內容,甚至隨著技術的演進,Coding Style也該與時俱進…可能這是個人比較龜毛的想法,但連Code Complete這本大作都一直沒完全看完的廢柴來說 (我啦) ,也只能砥礪自己不斷前進了。 (其實還想到goto這個議題,不過扯下去沒完沒了)

曾經有一個異想天開的想法,programmer應該都不太喜歡寫文件吧? 是不是可以藉由理想的Coding Style (包含命名及註解),讓code就像文件一樣易於閱讀,把對文件的依存度減到最低? 再怎麼說明的文件,不過就是在重複闡述既存的code?

當然自己也trace過那種繼承體系不易理解又沒文件的物件導向架構,有夠痛苦的,這個念頭暫時就是想想就好…

About David Yang

David Yang, like sports, nature, reading, music and...traveling. I am not good at sports, but like watching basketball, baseball and tennis games. I am not very strong, but like hiking, bushwalking and riding bicycle into the nature...Although I am a software engineer. Not only continue to read and gain knowledge, I also want to walk around every corner of the world. Here are some stories about my itineraries: https://dflucifer.wordpress.com/ I come from Taiwan...no matter where you meet me, either I am traveling, or just preparing for next trip :-)
This entry was posted in 軟體工程 and tagged , , , , , , . Bookmark the permalink.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s