談 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

• Indent style - Wikipedia, the free encyclopedia
• GNU Coding Standards
• google-styleguide
• Gary's的C/C++ coding standard - GaryLee
• C++ Programming Style Guidelines

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

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

Naming Convention (Naming Rule)

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

• 匈牙利命名法 - 極簡時尚 - udn部落格
• 匈牙利命名法#優缺點 - 维基百科，自由的百科全书
• 匈牙利命名法_百度百科

另外還有『駝峰式命名法』也是常見的

• 駝峰式大小寫 - 维基百科，自由的百科全书

根據不同的語言、平台，都有自己的一套命名法，這些『約定成俗』的名稱，我還沒辦法整理出可以遵循的 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 的文件。

• Doxygen簡介
• Doxygen 程式文件產生器 與 簡易筆記 | Tsung's Blog

c - Tools to get a pictorial function call graph of code - Stack Overflow
另外，在這篇有提到蠻多工具可以把 function call 畫成圖片，也就是流程圖，這對於 trace code 有些幫助！但 function call 應該是在 design 階段就劃分好，否則輸出的流程太雜亂幫助也不大。

小結

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