在罈子裡混了這麼久，看了很多同學的程式碼，感覺到大家的程式碼，學校裡面的書生氣有點重，對於細節考慮不夠，有時候，感覺和吃了顆蒼蠅一樣，確實很不舒服。
這裡根據我個人的經驗，給大家簡述一下，工程化程式碼，以及簡單程式碼，不容易出錯的程式碼的一些基本寫法。
1、工程化程式碼，首先考慮是團伙作案，獨行大盜的時代已經過去了，呵呵，因此，特別強調“人”能看懂，很多教科書上給出的示例，一切以計算機能正確run為準則，寫出的程式碼只有計算機能看，作者本人再看都要想半天，這不是好程式碼。
工程專案團隊，很多時候都是大家合作開發，你的程式碼，可能使用者不是你，下一個維護者也不一定是你，與人方便，與己方便，當有一天你對著一堆看不懂程式碼大罵的時候，想想，從我做起，給別人點方便。
2、簡簡單單寫程式，不是說惜墨如金，多敲一個字元都嫌累。
在Unix時代，沒有顯示器，都是電傳打字機，編輯器也是行編輯器，因此，每多敲一行字，都是錢，再加上那會記憶體小，編譯器能用的空間有限，因此，Unix的老程式設計師，對於變數名，函式名，標籤，珍惜得很，很少用2字元以上的，這是歷史因素，人家窮，小家子氣。
不過，現在大家用的都是以G為單位的記憶體，液晶顯示器，IDE又那麼強悍，拜託，起名字給長點，有點表意性好不好，別一段程式寫下來，滿篇都是“你猜”兩個字，看程式的人要瘋。
3、註釋，很多教科書，一說程式設計規範性，就是註釋，好像這是程式易讀的唯一方法，大學裡面的老師，沒見識過大型工程開發，沒一次幹過幾十萬，上百萬行程式碼，這麼說也是可以理解的。
不過，工程程式設計師，專案壓力一般都很重，在開發時，所有的注意力都在如何實現需求上，很少有人能有閒心，有耐心，精雕細琢自己的程式碼，甚至，很多程式碼，都是交工前最後一刻寫出來的，因此，要求詳細註釋，在工程開發中，實際上沒有可操作性。
起碼我自己都做不到，這就是為什麼我特別強調命名錶意，程式寫短點。即使程式設計師沒有註釋，看字面意思，也能大致理解。這麼說吧，看別人的工程程式碼，沒有註釋，是正常，有註釋，是福氣。
嗯，有時候是黴氣，很多程式設計師，開發時寫註釋，後期出現bug，開始瘋狂Debug的時候，那會哪有時間改註釋哦，能把程式改對，都是燒高香了，最後，很可能註釋和程式碼是反的，順著註釋看，順理成章就掉坑裡去了。
還是那句話，別期待註釋，別全信註釋，注意自己的程式，自身的表意性，至於你自己寫不寫註釋，如果在我的團隊裡面，.h檔案裡面的公有函式和方法，一定寫全，每個入口引數的含義，返回碼的含義，越多越好，別人正確呼叫你的程式，bug就不會找你麻煩，這是為了你自己。至於其他方面，愛寫不寫，我不管。
4、再說簡單，簡簡單單寫程式，可不是說你惜墨如金，是說讓讀的人，感到簡單，腦子裡不轉彎。這很好理解，我們做出一個產品，好不好，使用者說了算，你的軟體產品可能有特定的使用者，但你的程式碼本身，也是產品，你的團隊夥伴就是你的使用者，大家可能聽說過換位思考，我們寫程式的時候，除了想象客戶會不會罵娘，還有沒有想想，以後讀我們程式碼的人會不會罵娘？
團隊中有規範，按照規範來，不要討論合理不合理，先照做，大家養成閱讀習慣，看程式碼就不難。
寫程式碼，不要耍酷，年輕人，或多或少都有點愛表現自己的慾望，人之常情，可以理解，不過要控制。哪些為了一個演算法的優化，絞盡腦汁，最後把三個變數節約成一個變數，把四重迴圈節約成一重，看似水平高了，可是，演算法複雜度高了，看的人就暈了。
不想捱罵的話，老老實實的寫吧。函式內部的變數，只要不是動態申請的，一般都建立在浮動棧上，隨著函式的退出，就會自動拆除回收，給下一個函式使用。物件內部也差不多。所以，不妨多用幾個變數，老老實實地寫，不玩什麼花樣，看得人看得輕鬆，其實自己腦子也清晰，不容易出錯。
武俠小說中，說越是大宗師，越不喜歡用奇門兵器，一路簡簡單單的太祖長拳，破盡少林寺七十二絕藝，這說明什麼？把事情弄複雜，弄玄妙，不算本事的，能用最簡單的招式，化解最複雜的問題，內力夠了，自然可以。修煉內功，就是減少對招式的依賴，簡單，直接，直奔要害。以最小的成本，獲得最大的收益，大家說，是不是？
5、規矩，很多人，一說工程化開發，就認為程式設計規範很重要。於是開始找大公司的開發規範，於是，網上的華為軟體開發規範，傳來傳去，大家奉為聖旨。誰要敢說半個不字，管殺不管埋。
規矩是人定的，每個人群，每個開發團隊，都有自己的開發方向，常用工具，所以，程式設計規範其實是很小範圍的東東，都是針對目前專案最有效的，很難想象，一個做.net的開發團隊，拿著華為用gcc做VxWorks工程的程式設計規範，能做好事情。
什麼規矩是最好的？我的理解，最合用的就是最好的。系統設計完成，開發之前，專案團隊在一起開個短會，討論一下規範，把大的幾條定出來，之後就隨著專案的進行，不斷補充罷了。很多時候，專案經理也要尊重程式設計師的習慣，一個程式設計師用VC的IDE習慣，總不能為了寫gcc，強迫大家都用vi吧。這裡面有個個性化的規矩問題。
大家別不習慣，出去之後，走上社會，大家會發現，很多東東都是靈活的，不是一成不變的，很多人就在哭，這個世界太黑暗了。其實是自己不能靈活變通。專案組，有牛人，大家一般會跟著牛人走，他的惡習都可以變成團隊規矩，這也合理，沒有牛人，大家一盤散沙，就在介面處統一，裡面程式亂點沒啥，也可以，方法太多了，只要能出活，出來的程式碼，大家基本能看懂，其實就ok了。
像那種，還沒做事，先說一大堆規矩，程式設計師學習規矩和習慣養成都要半天，這些，最後都是專案成本。江山易改，本性難移，做專案管理，何苦來和每個人作對，尊重一下大家的習慣，直接把習慣做成規矩，不是更好？
6、輪子，筆者生活中，遇到很多了，罈子裡面喜歡拍磚的人，也不少，開口就說，這個世界需要依賴工具，自己造輪子的人是笨蛋。
這個話確實見仁見智。很難說對不對，不過，筆者建議，初學者還是少用別人的輪子。
大家畢業，走上工作崗位，還有幾十年呢。誰都不知道這輩子是不是一定在某個平臺，或者某種語言，某種框架下寫程式碼。
一旦年輕時，習慣了享受某種框架的便利性，就很難深入思考了。那隨著年紀增大，走向架構師崗位的時候，由於很多底層的特性思考不夠，會後繼乏力。我們說，出來混，總是要還的，現在享受了，但是，這輩子的債，總得換，到三四十歲再來重新學習研究，會很難的。
很多人大言不慚，一說就是框架，以框架搭建工程固然很快，但是，想想看，做框架的人，和用框架的人，哪個水平高？哪個收入高？其實很多時候，企業的架構師，就是針對專案或產品，為專案團隊制定本企業合用的框架的。
學著自己寫佇列，學著自己寫堆疊，再代入到實際工程中測試，做一些量身定做的優化，你的水平會迅速提升的。
先到這裡吧，感覺沒有講透，看大家有什麼問題，我再補充。