程式實驗室--ProgLab

今天在網路上看到一篇跟程式設計師有關的文章，標題是： 不廢話！五組程式碼，道盡 Coder 10 年幽幽練功路 。內容就真的是五組程式碼，看了真是很有感想。 一開始寫程式時就是簡單、笨笨的寫，後來有經驗了，就開始想要展現自己的能力，簡單的東西就寫得開始有點複雜了。又過了一些日子，經驗累積更多了，最後才領悟到簡單又可以達到目的的才是最美的。真所謂是反璞歸真啊。 的確，真正有能力的人不會把事情搞得很複雜來展現自己的能耐，反而是能切中要點，用最簡單的方式處理才是最厲害的。 這又讓我想到了最近看到的Bjarne Stroustrup C++之父在youtube上的一段演講，標題是： Make Simple Tasks Simple !"完整內容我還沒有時間看完，但我想大意應該是差不多的。 另外前不久也才剛看完Clean Code的中譯本： 無瑕的程式碼 。的確，寫程式寫到最後，真的是要用最簡單易懂的方式來處理，這樣未來自己再回頭看時，或是交接給後來的人維護時才不會太吃力。例如有關程式碼中註解的撰寫，如果是程式碼真接就容易看得懂的意思就不用再寫成註解了。因為這樣不但是多餘的，而且未來如果程式碼變更時而忘了去改註解的話，那真的會讓後來的接手維護的人不知這段到底是程式碼是正確的，還是註解是正確的。當然，前提是你的程式碼本身就可以明確地表達自己的意圖才好。

最早最早以前，一開始接觸程式設計時，就是在用Visual C++ 5.0 + MFC寫Windows程式。所以一開始的程式變數的命名規則都是學MFC裏的命名方式，也就是所謂 匈牙利命名法 。 匈牙利命名法倒是也沒什麼問題，我想他的起源應該是因為以前的C編譯器是不支援在編譯時檢查參數型別的，所以特別要在變數的前面加上型別的資訊，以便程式設計人員可以在編寫程式碼的時候就能夠有機會在第一時間查覺出所引用的變數型別上有出入，而不用等到程式真正編譯好執行時才發現錯誤。 而目前的程式語言及編譯器都已經能在編譯程式碼時就幫忙檢查引用的參數型別了，於是這種命名方式隨著時代的演進，應該是可以不用採用這種方式來命名了才對。 就開發程式設段時間以來，目前最常用到的就是兩種命名方式，一種是Pascal Case，另一種是Camel Case。 Pascal Case 變數的命名首字母是大寫，後續單字的第一個字母也都是大寫，例如TestSample。 Camel Case 有分成兩種，一種是Upper Camel Case，基本上就跟Pascal Case一樣。另一種是Lower Camel Case，變數的首字母是小寫，後續單字的第一個字母則都是大寫。例如testSample。 基本上這樣的方式也沒有誰好誰壞，只要有個規則，大家一致就好。 不過個人認為，如果是無型別檢查的環境下，變數的名稱(或一些需要命名的名稱)我習慣會加上型別的資訊。 例如在使用資料庫時，要為資料表及檢視表命名時，習慣上會加上tbl及vw的字首。用來識別這是資料表還是檢視表。 因為有些語法在檢視表上應該是不適用的，例如INSERT、UPDATE、DELETE這類的語法。檢視表只適合用來下SELECT的查詢語法。為了在使用時就能識別出是資料表或檢視表，個人覺得還是加上識別字比較好。 在C#或C++中我們可以宣告一個列舉，例如： public enum ServerStatusEnum { READY, IDLE } 在使用這種列舉型別來定義變數時，就可以： public ServerStatusEnum ServerStatus = ServerStatusEnum.IDLE; 因為我們想要的就是定義一個Server的Status，所以變數名稱當...