真正的程式設計師將**視為生命的結晶，從不浪費。然而，程式設計師並非天神，也會犯錯，所以沒有bug的**永遠不存在。為了打破宿命，程式設計師拼命修煉，似朝聖一般對**精益求精。由於程式設計師性格各異，各自修煉法訣千差萬別，單打獨鬥各有所長，但當共同面臨強大的武林公敵時，即便有高手壓陣，相互配合也顯得捉襟見肘，更不用說打敗強敵。鑑於此，大家便共同商討出乙個盟約以約束所有成員，保證力量的同向性，在臨陣對敵時發揮最大威力，而這個盟約便是編碼規範。
程式設計師的江湖從不平靜，每個程式設計師從來都是獨一無二的，但編碼規範卻試圖約束層出不窮的高手遵循統一的規則，這是有悖於人性的。儘管如此，不可否認的是每每出現強大的武林敗類時，遵循編碼規範總能旗開得勝，而無視編碼規範最終反被魔頭煉化。在一次次血的教訓下，所有程式設計師都意識到，遵守編碼規範原來是程式設計師的基本修養之一！
從某種程度上來講，編碼規範是程式設計師的天敵，而且編碼規範從來都是軟體開發中最混亂最具爭議的焦點之一，不同公司甚至同一公司不同產品或專案都有各自的編碼規範，有些規範甚至是相悖的。但是，要融入到乙個團隊中，便必須接受團隊的規範，如果有合理的建議再不斷改進。
《googlec++ style guide》
《高質量程式設計指南——c++/c語言》
其中，《googlec++ style guide》號稱全世界最優秀的編碼規範，確實可圈可點，但並不能一概而論，事實上很多企業並未採用。《高質量程式設計指南——c++/c語言》可能是很多程式設計師最先見到的編碼規範類資料了，其中諸多見解影響了很多程式設計師的一生。
1、 **注釋
**注釋是最簡單的規範，但卻是最混論的規範。本文並不試圖說教，但以下幾點在軟體開發中卻值得關注。
1) 注釋風格
很多使用過vc等ide環境的程式設計師很喜歡使用「//」注釋**，而不少從事低層c語言開發的程式設計師則習慣使用「/*……*/」注釋**，這兩種風格在當前c/c++開發中都是允許的，所謂蘿蔔白菜各有所愛。然而，一般情況下，建議單行注釋使用「//」，而多行注釋使用「/*……*/」，如下所示。
/*
本函式涉及tdm路由分配，未經允許嚴禁改動！！
如要改動，請遵循如下原則：
1.2.
*/bool tdmmanage(tdmroute &route)
// 列印顯示所有tdm路由
bool showtdmroutes(void)
儘管上述兩種注釋方式都是可行的，但並非通用的，有的編譯器只支援「/*……*/」注釋風格，例如鼎鼎大名的tornado。
2) 中英文注釋
中英文注釋同樣是令程式設計師糾結異常的乙個問題。其實大部分程式設計師都傾向於中文注釋，畢竟是自己熟悉的母語，可以十分清楚地闡述**意義，而英文則注釋起來十分蹩腳。事實上，很多編碼規範都建議優先使用中文注釋，即「中文注釋為主，英文注釋為輔」。
和注釋風格類似，中文注釋有時候是災難性的，英文注釋變成了唯一選擇。例如，在我所經歷的的乙個產品中，開始在windows上使用source insight編輯的中文注釋，將**移植到ubuntu上的eclipse後完全亂碼，不得不強制專案組使用英文注釋，且還需要將之前的中文注釋及時更正，無疑增加了極大的工作量。
關於中英文注釋，最後一點要強調的便是堅決抵制漢語拼音注釋！個人固執地以為，拼音注釋幾乎是程式設計師的恥辱，但貌似有人卻樂此不疲，我甚至見到某個模組的**全部使用拼音注釋，讓我不禁懷疑該「程式設計師」注釋的初衷及人品！
3) 注釋百分比
**是寫給程式設計師讀的，同樣是要交由程式設計師維護的，因此必要的注釋不可或缺，尤其對於產品維護更是如此。實際產品開發中，隨著需求的不斷推進，很多時候注釋是理解設計意圖的唯一指引，因此很多編碼規範都要求注釋百分比不低於一定數值。然而，此規範執行起來是有難度的，因為注釋並不能隨意新增，所謂「必要的注釋」尺度很難把握，只能取決於程式設計師的個人理解。需要強調的一點是，注釋並非越多越全便好，畢竟**不是文件。一般情況下，要求**注釋百分比不低於20%~30%。
與注釋百分比針鋒相對的是，很多武林高手認為「優秀的**都是自注釋的」。確實，通過良好的命名規範、設計模式、程式邏輯等的確可以使得**本身便闡述了其意圖，但問題在於這樣優秀的**有多少，或者說如此優秀的程式設計師有多少呢？因此，個人以為注釋仍是當前程式設計中不可或缺的重要組成，但程式設計師良好的修養可極大提高**自注釋水準，從而減少人為注釋。
4) 注釋更新
程式設計師們一定聽說過**腐爛或**膨脹等，注釋同樣存在類似問題。很多時候產品開發並非一蹴而就，其開發維護週期極長，尤其大規模商用的版本，其中產品**可能要經歷很多程式設計師的蹂躪。大多程式設計師都是慵懶的，或者更關注產品功能特性的，因此對注釋的維護更新可能不太關注。久而久之，後面的程式設計師不敢隨意刪除前輩們的注釋，而**又不斷變更，導致很多注釋與**不符，甚至是錯誤的。
注釋腐爛是滾雪球式的，到後面可能無法控制，因此優秀的程式設計師一定會及時更新自己所變更**的注釋，這是程式設計師基本的修養之一。
2、 命名規範
注釋可能是最混亂的規範，但命名則是最困難的規範。程式開發中的命名好似給小孩起名，每個程式設計師都希望起個好名字，但執行起來卻異常困難，給小孩有過命名經歷的人一定深有體會。鑑於此，命名規範希望借助統一的規則，最大限度地約束程式設計師命名方式，從而保證**風格一致。
命名規則中最鼎鼎大名且影響廣泛的當屬「匈牙利命名」，幾乎每一位程式設計師都深受其影響。在微軟諸如mfc等產品中，匈牙利命名的例子隨處可見。然而悲哀的是，目前為止沒有一種命名規則是被所有程式設計師認可的，因為其總有缺陷。這便是程式設計師的通病，總是高不成低不就！儘管如此，個人以為匈牙利命名仍是十分優秀的命名規則，事實上很多公司均採用其作為規範。
匈牙利命名規則並非本文討論的重點，本文想要強調的是，無論採用何種命名規範，在實際**開發過程中應該自始至終地貫徹執行，從而保持**整體風格一致！
3、 **格式
**格式本無需討論，但鑑於程式設計師對**的第一印象取決於**格式，本文對此仍進行簡單討論。
1) 空格
個人以為，**外觀核心因素取決於空格。空格包括語句內空格及與語句前空格，對於如何使用空格，本文不做深究，但如下**深刻展示了空格的巨大魅力。事實勝於雄辯，無需多言。
// 無空格
for (int j=(int)second.size()-1;j>=0;j--)
else }
// 有空格
for (int j=(int)second.size()-1; j>=0; j--)
else
}
2) 空行
儘管空行同樣會影響**外觀，但其更多的作用在**邏輯分割上。如下**中，儘管有無空行對程式功能毫無影響，但新增空行分割後，程式設計師的邏輯意圖便可清晰展現出來。
// 無空行
int sortbyrule(int digits, char *pstrinput, char *pstroutput)
for (int i=0; i本文對編碼規範的討論到此為止。實際上，編碼規範的內容很廣泛，本文僅對程式設計師們最常見的幾點進行了討論，其餘內容便望而生卻了，畢竟實在太過繁雜。
產品開發這幾年（6）目錄結構
如無意外，產品開發中的目錄結構一定為採用樹狀結構，這幾乎是所有系統架構師的唯一選擇。可能本人有幾分孤陋寡聞，但我固執地以為諸如網狀結構 線性結構等目錄結構可能有用武之地，但絕對是不得已而為之。或許有幾分武斷，但卻不可否認的是，樹狀結構是最符合人類邏輯思維的組織結構。避開產品開發不談，上至國家的政治體...
產品開發這幾年（2）介面抽象
軟體設計中各種介面隨處可見，如函式介面 子系統或模組之間的介面 不同產品之間的介面等，而介面抽象歷來是 仁者見仁，智者見智 一般情況下，我們得到的只是一些介面抽象的基本原則 建議，而程式設計師在具體開發中則大有 天高任鳥飛 的趨勢，不同程式設計師幾乎總可以抽象得到不同的介面。本文並不打算深入討論介面...
這幾年開發工作流的感受
在2002年學習工作流時 其實更早的時候也在做類似的專案,只不過當時還不知道有工作流這個叫法 聽過工作流的人都不多.而最進工作流炒的很火,似乎乙個企業平台如果沒有工作流就不上檔次.乙個oa,加個配置介面,在配置介面裡為幾個使用者分別指定幾個窗體,根據配置順序顯示給不同使用者不同窗體,將使用者在窗體中...