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