進入公司後看到的 Code 大部分都是用 匈牙利命名法 這個規則命名的。一開始的時候看到變數前面有m_、n、sz、lp等等一連串的怪怪 prefix ，讓本來就不懂的程式碼看起來更加痛苦。但是慢慢的了解了這個規則以後，發現到看別人的程式，如果有這樣的命名其實還不錯。
像是大家常常喜歡執行一個 Member Function 來改變 Member Variables ，當然程式如果是自己寫的很容易就知道那些 Member Variables 被修改了。但是這可苦了看你程式的人，尤其是沒有寫 Function 註解的時候。往往一個 Member Function 做完了以後，沒有回傳值，根本不曉得它到底做了些什麼。
所以說 匈牙利命名法 真的這麼好嗎？
在網路上搜尋的結果，發現到當然也是有人覺得它不錯，但是下面這篇討論，指出了它受到質疑的缺點 : 匈牙利命名法討論的文章。
當然缺點裡面有誇大的地方，不見得所有的地方都是不好的。Making Wrong Code Look Wrong(中文)這篇文章，就指出了 匈牙利命名法 最初的原意。它的用途在於知道變數的種類(Kind)，而不是型態(Type)。知道變數的種類(Kind)就能幫助看程式的人，從變數本身看出程式碼的錯誤。文章裡面也有舉了一個例子來說明。
所以當你使用 匈牙利命名法 來命名的時候，可以想想看這樣的做法是否可以幫助你了解程式，以及對程式的除錯是否有幫助。不然這樣的做法會讓程式的變數看起來眼花撩亂，可能跟你原本想要的結果大有不同 (最終目的是幫助程式的閱讀)。
參考資料 :發佈文章
Making Wrong Code Look Wrong(英文) - http://www.joelonsoftware.com/articles/Wrong.html
Making Wrong Code Look Wrong(中文) - http://chinesetrad.joelonsoftware.com/Articles/Wrong.html
匈牙利命名法討論的文章 - http://tsjeremy.spaces.live.com/blog/cns!BD4EB7F462639B16!1346.entry
2008年6月5日 星期四
| [+/-] |
關於匈牙利命名法的討論 |
| [+/-] |
程式碼的風格 (Coding Style) |
寫了這麼久的程式，但是對 Coding Style 卻沒有一個很明確的規範。常常變數寫怎麼取就怎麼取，因為以前寫的程式都是為了單一的目的 (通常是交作業) 而寫的。在進公司接了別人的程式以後，就深深的覺得好的 Coding Style 真的很重要。
像是變數的命名方式，如果在取名的時候不在 Class Member 前面加上 m_ 的前置符號，在看新的程式就會很難判別一個變數的範圍。往往在一個 Function 執行完以後，還不知道這個 Function到底做了些什麼事情，因為不曉得哪些變數是 Class Member 。帶大量參數的縮排也是一樣，好的縮排可以幫助我們很快的了解這個 Function 裡面的參數意義。當然我覺得最重要的還是在 Function 或是 Class 的前面可以加上註解會是更好的，常常你的小小註解，可以省下其他人 (更常是自己)很多時間。
下面這三份資料是介紹一些 Coding Style 的方法，分別是 C , C++ , C# 。但是我想基本概念都是差不多的。
C♯ Coding Style Guide
C++ Programming Style Guidelines
Recommended C Style and Coding Standards
希望大家的程式碼都是能容易閱讀的，讓看別人的程式碼變成是程式技術增進的快速方法，而不是一個痛苦的工作。
參考資料 :
C♯ Coding Style Guide - http://www.icsharpcode.net/TechNotes/SharpDevelopCodingStyle03.pdf
C++ Programming Style Guidelines - http://geosoft.no/development/cppstyle.html
Recommended C Style and Coding Standards - http://www.psgd.org/paul/docs/cstyle/cstyle.htm
2008年5月29日 星期四
| [+/-] |
寫註解的13個建議 |
在看別人的code時候, 往往因為文件不清楚, 或是註解不明確, 造成要了解程式必須要慢慢的去推敲過程. 這是非常浪費時間的事情, 因為往往只要知道程式流程, 就能掌握程式的精神. 對於細節的部分是不需要太去了解的, 除非程式存在bug.
所以寫好的註解可以幫助提升看程式的效率, 大多時候一個程式不會是從無到有. 而是會建立在別人的程式之上, 所以看程式的效率提升了, 寫程式的效率自然也會提升.
13 Tips to Comment Your Code這篇文章裡面就介紹了建議如何寫好的注解的方法.
除了註解以外, 文件也是很重要的. 除了大方向的程式運作之外, functions之間的運作流程也是幫助閱讀程式的好幫手. 尤其是寫event-driven的視窗程式, 如果能有各個功能的function流程, 能夠很快的幫助看程式的人了解程式運作, 而不需要自己去摸索猜測.
參考資料 :
13 Tips to Comment Your Code
http://www.cnblogs.com/oomusou/archive/2008/04/26/1172208.html