2013/03/26

談 Coding Style 與 Naming Convention

工作三年,回頭再來看看一些寫程式的基本 guideline,深深覺得小時候沒學好...

一個程式的週期不只有 key in 程式碼而已,包含了requirement、design、implementation、testing、maintenance。有一些好習慣從平常就要養成,習慣不好,程式寫得再快都沒有用,日後有可能在 maintenance 時就賠上了大半時間。

為了讓自己可以安穩的睡一覺,還是趁早把基礎打好吧。在網路上已經有很多現成的 rule 可以依循,不需要自己發明,除非用了以後發現有更適合自己的地方。



Coding Style

有句話是這麼說的:任何人都可以寫得出電腦看得懂的程式,但要讓『人』看得懂,不是一件容易的事情!
Run 比較久公司,可能內部自己就有一套 coding style,也可以在 google 搜尋一些 keyword: coding style, coding standard, programing guideline

自己就看得順眼的先找一套來使用吧,我自己寫 C 語言比較多,follow 的 style 比較偏向 K&R。

比較強的 IDE 都有內建排版,像是 Eclipse 預設就有 K&R、BSD、GNU...等方式,也可以根據樣板再去做修改,透過軟體排版會快很多。



Naming Convention (Naming Rule)

好的命名法對於程式可讀性是會大大加分的,其範疇包含了程式內部變數、檔案名稱、外部參數,其實命名法也沒有一個制式規定,但有一些約定成俗的法則。
最常聽到的應該是『匈牙利命名法』,有很清楚的規範,但如果完全照著走就會發現變數變得很冗長...
另外還有『駝峰式命名法』也是常見的


根據不同的語言、平台,都有自己的一套命名法,這些『約定成俗』的名稱,我還沒辦法整理出可以遵循的 rule,真的得靠臨摹別人的程式來習得,多看一些 open source project 吧。



Documentation

Programer 好像都蠻討厭寫文件的,但很抱歉,你可能需要開 API 給別人,日後需要轉交給同事,或是自己因為時間久了也會忘記,所以寫文件真的蠻必要的。
Software design document (SDD) 算是我有認為比較常用的一種,裡面包含了 data design、architecture design、interface design、procedural design。但真正常用的還是只有 data structure 與 API,這時候就要介紹一下 doxygen,也就是把文件跟 code 結合在一起,方便維護。按照 doxygen 的格式去寫註解,最後可以產生 html 或 pdf 的文件。
c - Tools to get a pictorial function call graph of code - Stack Overflow
另外,在這篇有提到蠻多工具可以把 function call 畫成圖片,也就是流程圖,這對於 trace code 有些幫助!但 function call 應該是在 design 階段就劃分好,否則輸出的流程太雜亂幫助也不大。



小結

Vgod曾說過:好的程式設計師跟普通的程式設計師,效率可以差上幾十倍甚至幾百倍。除了上述的 coding 習慣、使用工具、開發環境...種種細節都會影響到,在拼專案之餘,也花些時間注重這些東西吧,一起往神人的境界努力!如果還有其他關於基礎學習,我再更新上來。


13 則留言: