[轉錄]Coding Style - 程式設計風格對軟體開發的影響

看板Programming作者jacana (Share)時間17年前 (2007/05/06 20:00)推噓5(5推 0噓 5→)

留言10則, 7人參與討論串1/1

原文有圖還蠻好笑的 http://mmdays.wordpress.com/2007/04/24/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這種東西有什麼好談的？」其實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 Conventions for the Java Programming Language * C++ Programming Conventions * Pascal Style Guide * Mozilla Coding Style Guide * Linux Coding Style * Hungarian Notation: 這個要特別講一下，這是微軟在1980年代搞出來的一種取名方式，如果你看過Win32 API或是現在還在跟MFC奮戰的話，你對於這個notation一定不會陌生。這種style引起相當大的爭議，因為程式之中會出現一些名字相當怪異的變數或是 class名稱，看起來很醜。所以除非你有志跟微軟的那些東西長期相處，不然我個人是覺得平常寫程式實在沒有必要學這種notation。 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來達到離線溝通的目的就顯得更為重要。而當我們寫程式時，最重要的認知就是我們寫出來的軟體，是要給別人和自己維護的，不是寫完可以跑就算了，記住要和大家取得寫程式共識，不要覺得寫到別人看不懂才能證明自己的功力高深。寫大家都看不懂的東西誰都會，但是寫到每個人都可以看得懂就真正是一門大學問了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 125.225.111.214

推

m1ssU

05/06 20:14, , 1^F

05/06 20:14, 1^F

→

jaw109

05/06 21:00, , 2^F

05/06 21:00, 2^F

→

jaw109

05/06 21:01, , 3^F

05/06 21:01, 3^F