Coding Style – 程式設計風格對軟體開發的影響

Posted by Mr. Saturday

寫程式的人都或多或少會有這種感覺,別人的code看起來總不是那麼地順眼,閱讀自己的code才是像閱讀好書一樣如行雲流水般順暢。其實寫code如寫書,不僅寫給自己看,同時也寫給別人看;開發軟體也往往有如打造一件工藝品,投入其中的巧妙心思及用心,會影響到最後呈現出來的結果。所以,寫程式本身可以是一種藝術,而不僅僅是一件耗費勞力的枯燥工作。這也是為什麼Knuth要把他的巨著取名為The Art of Computer Programming,他認為打造軟體是困難的,是一種複雜度以及最後呈現結果足夠作為一件藝術品的一種過程。當然以Mr. Saturday的觀點來看,要邁入如創造藝術品般地去打造軟體這樣的一個境界,實在不是我們這種實力淺薄之人一日可成的事。所以,我還是比較喜歡寫code如寫書這個切入點。

既然寫code如寫書,那麼最重要的就莫過於條理清晰,脈絡分明的內容了,於是我們就需要一套令人容易了解的呈現手法來寫作了,一方面讓自己好讀,一方面也讓讀者好讀:於是coding style這種東西就出現了。這篇文章就是要來跟大家簡單介紹一些寫code最為常用的coding style,以及一般programmer彼此之間常常存在的有趣現象。

coding-style-comic

可能有人會覺得:「coding style這種東西有什麼好談的?」其實coding style說起來還真沒什麼學問,不過就是寫code的一些風格罷了。但是一般programmer常常會忽略的是,他們寫code其實是給三種觀眾看:

  • 給compiler看:這是每個programmer都會記得的事情,所以他們會確保自己寫出來的東西不會讓compiler抱怨,或是吐出一堆垃圾,因此他們會乖乖地遵循著programming language的語法,好好地寫給compiler看,小心翼翼地不要犯錯。compiler不會計較你寫code的style,只要compiler看得懂,就一切ok。
  • 給自己看:不幸的是,很多人從頭到尾都沒想到,寫code也要寫給自己看,而且不僅僅是讓自己現在看得懂,也要讓自己以後看得懂,很多programmer年輕氣盛,在程式裡用了高超的語法和神奇的bitwise technique,寫了執行速度快人一等的程式,卻就是忘了寫注解,十年後翻開一看,雖然大概知道以前用的技巧和語法,卻要重新咀嚼一番才能完全理解,想想如果此時十年前的你可以來跟你解釋,不是挺好?所以別忘了把自己也當成是潛在的讀者。
  • 給其他人看:project的deadline快到了,只剩沒幾天可以趕code,還要算算整個程式兜起來compile所需要花的時間,現在這種情況下,能有東西交差就不錯了,還管什麼style和註解啊。ok,連夜趕工過了幾天終於寫完了,但是下一個project又接踵而至,哪還有時間回頭去把code好好重新整理一番?註解?等我有空再說吧。(結果真的有空了也跑去上MSN聊天)

於是在業界,我們往往就會看到一大堆沒有註解和coding style混亂的code,一打開檔案,我們嘴裡就開始不停咒罵這些該死不寫註解、還以為全世界的人都有義務看得懂他的code的宅男。然後一年後,換成另外一批人在咒罵我們。軟體界就是如此生生不息。根據業界的統計,一個軟體的生命週期之中,有80%是花在維護上面,讓他人容易讀懂和維護你的code,對於軟體的成功和演進至關重要。Mr. Saturday曾經接到一個有關Robotics的專案,是要寫機器人運作的軟體,這個軟體之中有關kinematics的部分已經完成了,我要負責做的是search的演算法,但是search過程中總是需要去度量機器人現在的kinematics,於是乎我打開了前人寫好的部分,準備好好研究一番。結果一看不得了,幾十個source code的檔案,加一加三千多行的程式碼,顯然出自於多人之手,不僅coding style混亂,更糟的是註解不超過10行!一看真是整個呆掉,寫信去問之前的開發者也是久久沒有回音。(其實就算得到回音,我還真的是不知道要從何問起。)結果最後就演變成,我和我的team member另外寫code去猜和測試這些沒有註解的程式是在做什麼!真是有夠心酸。腦細胞也因此壞死一堆。

在業界一些比較大型的軟體公司,自然會有一套方法來避免這種現象,所以coding standard應運而生。作為一個新進人員,閱讀公司制定出來的coding standard絕對是新進訓練時不可或缺的一環。如果公司自始至終都沒有給你看內部慣用的coding standard,那這家公司的軟體開發水準,恐怕就要畫上一個問號了。如果你現在只是一個自學程式,寫寫學校作業和project的學生,培養好的coding style對你來說同樣重要,因為業界很多的自訂標準,脫離不了一些經典的coding style,以下簡單列出一些給大家參考:

Coding Style沒有絕對的好與壞。一但你選定自己遵循的規則後,之後最重要的就是維持這個style的一致性,不要變來變去。
另外,不僅僅是針對programmer而已,coding style對於project manager有時甚至更重要,你身為一個project manager,絕對不能讓自己手下幾個programmer在coding style上有各自為陣的機會,如此一來整個專案將會非常難以維護,programmer彼此之間用code來進行的溝通也會遇到阻礙,最後完成的軟體看起來也會像是拼拼湊湊出來的樂高,相當不專業。因此,在專案初期,根據公司普遍的標準制定該專案的coding style是相當重要的一件事情,此時就有幾件事情需要考慮:

  • 有幾個coder參與這個專案
  • 他們平常的coding style是如何,注意那些喜歡寫怪code的人
  • 制訂出一個大家都滿意的coding standard,至少要取得共識
  • 明確規範coding style,包括縮排、大小寫、括號的位置以及註解的型式等等,都要有簡單的範例和規章來明確說明
  • 定期追蹤他們寫出來的東西,不要讓他們的code隨著時間漸漸偏離訂好的coding standard

好的coding style是建構軟體相當重要的前置作業,現在的project鮮少是由一人獨力完成,以同樣的coding style來達到離線溝通的目的就顯得更為重要。而當我們寫程式時,最重要的認知就是我們寫出來的軟體,是要給別人和自己維護的,不是寫完可以跑就算了,記住要和大家取得寫程式共識,不要覺得寫到別人看不懂才能證明自己的功力高深。寫大家都看不懂的東西誰都會,但是寫到每個人都可以看得懂就真正是一門大學問了。

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!
  • 我也很不喜歡匈牙利命名法…
    看到一堆數字命名為nTotal, szTitle就賭爛….XD

  • 我也很不喜歡匈牙利命名法…
    看到一堆數字命名為nTotal, szTitle就賭爛….XD

  • Good and concise article. I will give it 100 points!

  • Good and concise article. I will give it 100 points!

  • 恩! 一針見血

  • 恩! 一針見血

  • 匈牙利命名法其實也沒那麼糟糕 (惡名昭彰),
    詳見 Joel on Software [讓錯的程式看得出錯]: http://chinesetrad.joelonsoftware.com/Articles/Wrong.html

  • 匈牙利命名法其實也沒那麼糟糕 (惡名昭彰),
    詳見 Joel on Software [讓錯的程式看得出錯]: http://chinesetrad.joelonsoftware.com/Articles/Wrong.html

  • 我也贊同Hemidemi 裡 Ludan 說的,選一個合理的Style然後執行到最後。不過執行還是最困難的。人都是有惰性的,加上一但靈感來了,Code就一直冒出來,很難在寫的過程中停下來寫註解。Code寫完後也懶的回頭寫了。這時候只能靠流程了。好的流程才能確保code的品質呀。不過說到流程,又是一個話題了。

  • 我也贊同Hemidemi 裡 Ludan 說的,選一個合理的Style然後執行到最後。不過執行還是最困難的。人都是有惰性的,加上一但靈感來了,Code就一直冒出來,很難在寫的過程中停下來寫註解。Code寫完後也懶的回頭寫了。這時候只能靠流程了。好的流程才能確保code的品質呀。不過說到流程,又是一個話題了。

  • abc

    各自為陣 應為「各自為政」

  • abc

    各自為陣 應為「各自為政」

  • Adam

    同意eric 大的說法。
    其實匈牙利命名法沒有那麼糟糕,糟糕的是微軟的那群人,誤解了匈牙利命名法的真意。然後因為邪惡微軟制定的WIN32 API,大家只好跟著用。然後用了覺得又臭又長的變數名稱看得很不爽,就開始咒罵匈牙利命名法。
    Joel on Software 的文章真的很不錯喔~ 推薦大家看看~ 🙂

  • Adam

    同意eric 大的說法。
    其實匈牙利命名法沒有那麼糟糕,糟糕的是微軟的那群人,誤解了匈牙利命名法的真意。然後因為邪惡微軟制定的WIN32 API,大家只好跟著用。然後用了覺得又臭又長的變數名稱看得很不爽,就開始咒罵匈牙利命名法。
    Joel on Software 的文章真的很不錯喔~ 推薦大家看看~ 🙂

  • Pingback: Top Posts « WordPress.com()

  • 你blog的banner照片是不是LAKE TAHOE??在 Emerald Bay往下看T-house…
    難得看到有人有去過THAHOE說,下次記得可以去住我們的motel歐!

  • 你blog的banner照片是不是LAKE TAHOE??在 Emerald Bay往下看T-house…
    難得看到有人有去過THAHOE說,下次記得可以去住我們的motel歐!

  • 匈牙利命名法確實沒什麼不好,尤其是在組合語言和 C 語言的 coding 場合。它們沒有便利的 casting ,一個指標或一個整數沒什麼差別。不加個記號說明一下型態, coding 工作可要命了。總不成把 struct 印成一張速查表貼在電腦螢幕旁吧?每寫一個變數,就瞄一下看看這變數是啥型態。一個 dwID 和一個 szID ,就可以減少不少錯誤。至少不會把整數(dword)的 dwID 當成字串指標;也不會把 szID 當成數值代號。

    當然在C++或動態語言中,這種命名法就毫無意義了。大多數情形下會自動轉型,故 “1” == 1 is true.

  • 匈牙利命名法確實沒什麼不好,尤其是在組合語言和 C 語言的 coding 場合。它們沒有便利的 casting ,一個指標或一個整數沒什麼差別。不加個記號說明一下型態, coding 工作可要命了。總不成把 struct 印成一張速查表貼在電腦螢幕旁吧?每寫一個變數,就瞄一下看看這變數是啥型態。一個 dwID 和一個 szID ,就可以減少不少錯誤。至少不會把整數(dword)的 dwID 當成字串指標;也不會把 szID 當成數值代號。

    當然在C++或動態語言中,這種命名法就毫無意義了。大多數情形下會自動轉型,故 “1” == 1 is true.

  • JY

    關於作者 coding style 諸點,我有些意見:

    * 有幾個coder參與這個專案
    * 他們平常的coding style是如何,注意那些喜歡寫怪code的人
    * 制訂出一個大家都滿意的coding standard,至少要取得共識

    如果團隊中有強制訂定 coding style 的需要,那就表示沒有一套 coding style 能讓大家滿意的,尤其是規定到縮排、大小寫、括號位置等等較細項目。除非獨裁權威式的規定,否則常常最後都會落到失敗的下場。

    * 明確規範coding style,包括縮排、大小寫、括號的位置以及註解的型式等等,都要有簡單的範例和規章來明確說明

    這些東西需要規範,但不需要訂的太嚴苛,遵循可讀性原則即可。甚至這些規範只需要在某種特定範圍達到一致就好,無須全域式的套用所有程式碼,重點還是在於可讀性。我認為縮排、大小寫、括號的位置有些許差異並不至於傷害可讀性,一套容易執行 coding style 會比較有用。

    個人習慣用 Linux Coding Style (K&R),但在公司使用類 Hungarian Notation 或混合的方式,並沒有對我產生多大困擾。

    * 定期追蹤他們寫出來的東西,不要讓他們的code隨著時間漸漸偏離訂好的coding standard

    誰來做這件事?PM?你在開玩笑嗎? *grin*

  • JY

    關於作者 coding style 諸點,我有些意見:

    * 有幾個coder參與這個專案
    * 他們平常的coding style是如何,注意那些喜歡寫怪code的人
    * 制訂出一個大家都滿意的coding standard,至少要取得共識

    如果團隊中有強制訂定 coding style 的需要,那就表示沒有一套 coding style 能讓大家滿意的,尤其是規定到縮排、大小寫、括號位置等等較細項目。除非獨裁權威式的規定,否則常常最後都會落到失敗的下場。

    * 明確規範coding style,包括縮排、大小寫、括號的位置以及註解的型式等等,都要有簡單的範例和規章來明確說明

    這些東西需要規範,但不需要訂的太嚴苛,遵循可讀性原則即可。甚至這些規範只需要在某種特定範圍達到一致就好,無須全域式的套用所有程式碼,重點還是在於可讀性。我認為縮排、大小寫、括號的位置有些許差異並不至於傷害可讀性,一套容易執行 coding style 會比較有用。

    個人習慣用 Linux Coding Style (K&R),但在公司使用類 Hungarian Notation 或混合的方式,並沒有對我產生多大困擾。

    * 定期追蹤他們寫出來的東西,不要讓他們的code隨著時間漸漸偏離訂好的coding standard

    誰來做這件事?PM?你在開玩笑嗎? *grin*

  • 我認為制定 coding style是一定會有的,但是大家以為定好了就可以了。其實執行的制度才是重點。沒有糟糕的coding style,只有糟糕的制度。

  • 我認為制定 coding style是一定會有的,但是大家以為定好了就可以了。其實執行的制度才是重點。沒有糟糕的coding style,只有糟糕的制度。

  • Adam

    對我來說 coding style 到是不需要訂到這麼嚴苛,只是希望不要出現同一個人寫的 code 對齊或縮排都不一致,才真的很痛苦。

  • Adam

    對我來說 coding style 到是不需要訂到這麼嚴苛,只是希望不要出現同一個人寫的 code 對齊或縮排都不一致,才真的很痛苦。

  • Newtype

    其實縮排可以藉由一些工具來解決。撰寫java的話可以利用eclipse自訂coding style的功能,C++的話就要看有沒有另外的工具了。(印象中是有)

  • Newtype

    其實縮排可以藉由一些工具來解決。撰寫java的話可以利用eclipse自訂coding style的功能,C++的話就要看有沒有另外的工具了。(印象中是有)

  • 感謝大家給予相當寶貴的回應
    讓我又學到了不少東西
    另外眼尖的hunter認出我們的banner是在Lake Tahoe拍攝的照片
    沒錯~~我們不定時會換一些banner,大部分都是我們在各地拍攝到的漂亮照片
    Lake Tahoe也是我旅行去過的地方之一,相當漂亮的一個地方
    沒想到hunter在當地經營INN!
    我們的讀者連Tahoe都有,真是太令人興奮了:D

  • 感謝大家給予相當寶貴的回應
    讓我又學到了不少東西
    另外眼尖的hunter認出我們的banner是在Lake Tahoe拍攝的照片
    沒錯~~我們不定時會換一些banner,大部分都是我們在各地拍攝到的漂亮照片
    Lake Tahoe也是我旅行去過的地方之一,相當漂亮的一個地方
    沒想到hunter在當地經營INN!
    我們的讀者連Tahoe都有,真是太令人興奮了:D

  • 有關 Hungarian programming 的笑話: (來自 Andy Hertzfeld 的 “Revolution in the Valley”) 最早的 Mac OS 的 memory manager 其實是從 Lisa (麥金塔的前身) 移植過來的. 麥金塔部門的程式設計師拿到 Lisa memory manager 原始碼的時候嚇了一大跳, 因為所有的變數名稱都只有子音! 沒有母音的變數名稱非常難讀, 沒有人看得懂. 原來 Lisa 的程式設計師是 Charles Simonyi 的學生, 他從 Simonyi 那兒學來了 Hungarian notation. 不過當時 Pascal compiler 的變數名稱只能有 8 個字元, 用了 Hungarian notation 後, 變數的名稱常常只能有四個字元, 所以只好拿掉母音. Mac 的程式師 Budd Tribble 後來花了很多時間拿掉 Hungarian notation, 並且把母音加回去.

    Charles Simonyi 本來是 Xerox Parc 的研究員, 後來加入 Microsoft. Microsoft 之所以會用 Hungarian notation, 大概都是因為 Simonyi 關係. 據說他最近上了太空. [板主: 抱歉, 我又 post 跟主題無關的笑話. 而且大概不是很好笑.]

  • 有關 Hungarian programming 的笑話: (來自 Andy Hertzfeld 的 “Revolution in the Valley”) 最早的 Mac OS 的 memory manager 其實是從 Lisa (麥金塔的前身) 移植過來的. 麥金塔部門的程式設計師拿到 Lisa memory manager 原始碼的時候嚇了一大跳, 因為所有的變數名稱都只有子音! 沒有母音的變數名稱非常難讀, 沒有人看得懂. 原來 Lisa 的程式設計師是 Charles Simonyi 的學生, 他從 Simonyi 那兒學來了 Hungarian notation. 不過當時 Pascal compiler 的變數名稱只能有 8 個字元, 用了 Hungarian notation 後, 變數的名稱常常只能有四個字元, 所以只好拿掉母音. Mac 的程式師 Budd Tribble 後來花了很多時間拿掉 Hungarian notation, 並且把母音加回去.

    Charles Simonyi 本來是 Xerox Parc 的研究員, 後來加入 Microsoft. Microsoft 之所以會用 Hungarian notation, 大概都是因為 Simonyi 關係. 據說他最近上了太空. [板主: 抱歉, 我又 post 跟主題無關的笑話. 而且大概不是很好笑.]

  • Pingback: The Way I Believe ::PIXNET BLOG::()

  • Moun

    First of all, i have to say sorry I’m writing in English .. ’cause my chinese typing is tooooo slow.

    I have to agree with that standards for coding style in one application have to be set prior to the coding begins. Otherwise, it will cause a lot of confusion while reading other ppl’s code. In my case, my team lead wrote a “procedure manual” that has everything. Everything meaning : naming convention, region setup (in c#), variable order pulic, private then const). The only problem is that it needs to be read thoroughly and take time to get used to it(which i had some trouble in the begining >,

  • Moun

    First of all, i have to say sorry I’m writing in English .. ’cause my chinese typing is tooooo slow.

    I have to agree with that standards for coding style in one application have to be set prior to the coding begins. Otherwise, it will cause a lot of confusion while reading other ppl’s code. In my case, my team lead wrote a “procedure manual” that has everything. Everything meaning : naming convention, region setup (in c#), variable order pulic, private then const). The only problem is that it needs to be read thoroughly and take time to get used to it(which i had some trouble in the begining >,

  • 恩,其實我們老師ㄧ直要求我們要加註解,但是我通常都懶得加,也有改別人的code沒加註解看不懂全部重寫的經驗,看了這篇文章,哈~看來我是要好好有耐心的加註解了(話說回來我也有好幾個禮拜偷懶沒寫ACM了,快要期末結算了…)

  • 恩,其實我們老師ㄧ直要求我們要加註解,但是我通常都懶得加,也有改別人的code沒加註解看不懂全部重寫的經驗,看了這篇文章,哈~看來我是要好好有耐心的加註解了(話說回來我也有好幾個禮拜偷懶沒寫ACM了,快要期末結算了…)

  • 個人覺得執行才是重點,有人就是覺得coding style不重要,對project沒幫助,所有其他人都有遵守才願意修正,找一堆理由不願意改,能怎麼辦!!fire他嗎?

  • SamLaio

    後來覺得最重要的反而是最不引人注目的”注解”
    因為後來看code的人(不管是誰),有了注解後,就能很快速的了解程式是在做啥鬼,而不是要再跟著羅輯跑個好幾團才了解。

  • Pingback: 塑料网()

  • Pingback: 安平物流网()

  • Pingback: 勾花网()

  • Pingback: 伸缩缝()