引語：代碼風格，是一個工程師長期以來養成的一些編寫代碼的習慣，其實并無絕對的好壞之分！但是，基本上可以這么說，一個有很好的代碼風格的人，技術水平絕不會太低；反之，一個沒有好的代碼風格的人，技術水平也不會高到哪里去，即使是他已經有很多年的編程經驗！因為，在業界有一個不成文的現象，那就是每個工程師都有一個追求技術提升，追求完美的夢！結果就是，隨著個人技術水平的提高，風格也越來越成熟，而這個風格就體現著其個人水平！

本文以PHP語言的某微視角，說幾個代碼風格上的事，同理可推至其他語言，其他技術，甚至其他通用道理！

本文將以從面到線再到點的過程，講述一些個人心得。僅供大家娛樂參考，如有不對，請多多指教。如有雷同，不勝榮幸！

本文就以一個虛擬項目作為線索吧！

1、面：所謂面，就是面對一個項目擺在眼前，怎樣去部署大方向的問題的思路！準確的說，這里并不是真正地體現一個代碼風格，而是一個做事風格！

風格1：1. 我需要需求書，書上怎么寫，我就怎么做；2. 如果有一些未知的技術，盡量讓需求上做一些讓步，以減少開發難度；3. 找個牛逼的人，帶著自己或其他人一起做；4. 時間是多久？

風格2：1. 我需要需求書，書上寫的東西，清楚嗎？有什么可要可不要的東西，有副作用嗎？2. 大概需要什么樣的輔助工具，在哪里可能會得到這些東西？3. 我怎樣組建自己的技術團隊？4. 時間是多久？5. 后期可能會有什么樣的擴展？

2、線：所謂線，可以理解為流水線吧。就是怎樣去完成這么一個計劃，怎樣調動生產？

風格1：1. 設計數據庫； 2. 選擇代碼框架；3. 編碼；

風格2：1. 設計服務架構；2. 模塊細化；3. 設計數據庫； 4. 選擇代碼框架；5. 編碼；

3、 點：所謂點，其實才這里說的真正的代碼風格，將著重說明一些。

風格1：任性，隨意而為，沒有規則！

風格2：著重講解！

3.1. 不一定非要使用現有成熟框架，但是一定要有MVC的概念，基本要拋棄面向過程編程方式，采用面向對象，不任性；

3.2. 結合多種設計模式進行開發，如單例模式、工廠模式、抽象模式、觀察者模式等等，這些都是成熟的概念，都要盡量多用！優雅，大氣，效率，易讀；

3.3. 類內部變量定義以權限放第一位，變量修飾符放第二位，以重要程度分先后，如 public static function fun1（）{} ；類名與文件名有某種特定程度的相同，方便查看；類名統一首字母大寫；私有變量或方法使用下劃線開頭以區分，如 private function _doCut（$data）；文件以最能體現其功能的單詞命名，區分類型，如 IndexController.class.php， function.inc.php;

3.4. 文件內部使用統一命名方式，要么使用下劃線方式命名，如 $get_child，$bind_value，要么使用駝峰式命名，如 $getChild，$bindValue；變量名盡量使用全名不要使用簡寫，如 getCategory不要簡寫成getCat；

3.5. 多個參數之間有逗號分隔時，逗號后要留一個空格如 fun（$param1， $param2）;運算符兩邊均有一個空格（數組對齊除外），如 $click = 123；

3.6. 避免使用global變量，尤其是有些不是公共初始化時產生的變量；

3.7. 杜絕函數內部include方法文件，因為這樣很難找到真正起作用的方法，或者說方法混亂；

3.8. 使用自動加載方式，而非include方式；

3.9. 如果一定要包含文件，盡量使用include_once，require_once 避免一個文件被引入多次從而報錯情況；

3.10. 對可能多次引用的全局變量，使用某類的靜態方法進行獲取，如 ConfigClass：：get（‘main’， ‘field’）; 對于數據庫一類連接，使用靜態變量，保存首次連接時打開的連接，從而多處使用DB實例時，仍然不會重復實例化，如 $db = ConfigClass：：getDbInstance（）;

3.11. 多使用isset（）， empty（）等系統函數進行判斷空操作而非 ！$var， $var == null;

3.12. 對于使用兩次以上方法，就應該去考慮提出到公用地方或者類中；

3.13. 數據查詢先確認當前索引，配合寫SQL，特別地方，一定加上注釋；

3.14. 會使用文件鎖，數據庫鎖，會使用緩存如 memcache， redis， mongodb等；

3.15. 會適當使用事務；

。..

好吧，晚了，洗洗睡吧。有空再補補。總之，一些小細節，總是要用經驗堆砌才會真的明白！

其實，好與不好，大家已早有定論，只是作個參考，罷了！

習慣，就好！