php的編碼規則

1. 介紹
1.1. 標準化的重要**
標準化問題在某些方面上讓每個人頭痛，讓人人都覺得大家處於同樣的境地。這有助於讓這些建議在釵h的專案中不斷演進，釵h公司花費了釵h星期逐子字逐句的進行爭論。標準化不是特殊的個人風格，它對本地改良是完全開放的。
1.2. 優點
當一個專案嘗試著遵守公用的標準時，會有以下好處：
﹒ 程式設計師可以瞭解任何程式碼，弄清程式的狀況
﹒ 新人可以很快的適應環境
﹒ 防止新接觸php的人出於節省時間的需要，自創一套風格並養成終生的習慣
﹒ 防止新接觸php的人一次次的犯同樣的錯誤
﹒ 在一致的環境下，人們可以減少犯錯的機會
﹒ 程式設計師們有了一致的敵人
1.3. 缺點
﹒ 因為標準由一些不懂得php的人所制定，所以標準通常看上去很傻
﹒ 因為標準跟我做的不一樣，所以標準通常看上去很傻
﹒ 標準降低了創造力
﹒ 標準在長期互相合作的人群中是沒有必要的
﹒ 標準強迫太多的格式
1.4. 討論
釵h專案的經驗能得出這樣的結論：採用程式設計標準可以使專案更加順利地完成。標準是成左疑鶬鉹？當然不。但它們可以幫助我們，而且我們需要我們能得到的所有 的幫助！老實說，對一個細節標準的大部分爭論主要是源自自負思想。對一個合理的標準的很少決定能被說為是缺乏技朮**的話，那只是口味的原因罷了。所以， 要靈活的控制自負思想，記住，任何專案都取決於團隊合作的努力。[@more@]1.5. 解釋
1.5.1. 標準實施
首先應該在開發小組的內部找出所有的最重要的元素，也頃衪蓍鴽A的狀況還不夠恰當。它可能已經概括了 重要的問題，也可能還有人對其中的某些問題表示強烈的反對。無論在什仃〞p下，只要最後順利的話，人們將成熟的明白到這個標準是合理的，然後其他的程式設計師 們也會發現它的合理**，並覺得帶著一些保留去遵循這一標準是值得的。如果沒有自願的合作，可以制定需求：標準一定要經過程式碼的檢驗。如果沒有檢驗的話， 這個解決方案僅僅是一個建立在不精確的基礎上的一大群可笑的人。
1.5.2. 認同觀點
1. 這行不通﹔
2. 也野i行吧，但是它既不實用又無聊﹔
3. 這是真的，而且我也告訴過你啊﹔
4. 這個是我先想到的﹔
5. 本來就應該這樣。
如果您帶著否定的成見而來看待事物的話，請您保持開放的思想。你仍可以做出它是廢話的結論，但是做出結論的方法就是你必須要能夠接受不同的思想。請您給自己一點時間去做到它。
1.5.3. 專案的四個階段
1. 資料庫結構
2. 設計
3. 資料層
4. HTML層
2. 命名規則
2.1. 合適的命名
命名是程式規劃的核心。古人相信只要知道一個人真正的名字就會獲得凌駕於那個人之上的不可思議的力量。只要你給事物想到正確的名字，就會給你以及後來的人帶來比程式碼更強的力量。別笑！
名字就是事物在它所處的生態環境中一個長久而深遠的結果。總的來說，只有瞭解系統的程式設計師才能為系統取出最合適的名字。如果所有的命名都與其自然相適合，則關系清晰，含義可以推導得出，一般人的推想也能在意料之中。
如果你發覺你的命名只有少量能和其對應事物相匹配的話， 最好還是重新好好再看看你的設計吧。
2.2. 類命名
﹒ 在為類（class ）命名前首先要知道它是什醜C如果透過類名的提供的線索，你還是想不起這個類是什雲爾隉A那之A的設計就還做的不夠好。
﹒ 超過三個片語成的混合名是容易造成系統各個實體間的混淆，再看看你的設計，嘗試使用（CRC Session card)看看該命名所對應的實體是否有著那丹h的孕峞C
﹒ 對於派生類的命名應該避免帶其父類名的誘惑，一個類的名字只與它自身有關，和它的父類叫什今L關。
﹒ 有時字尾名是有用的，例如：如果你的系統使用了代理（agent ），那仍N把某個部件命名為“下載代理”（DownloadAgent）用以真正的傳送資訊。
2.3. 方法和函式命名
﹒ 通常每個方法和函式都是執行一個動作的，所以對它們的命名應該清楚的說明它們是做什雲滿G用CheckForErrors()代替ErrorCheck ()，用DumpDataToFile()代替DataFile()。這什竣]可以使弁鄔M資料成為更可區分的物體。
﹒ 有時字尾名是有用的:
o Max - 含義為某實體所能賦予的最大值。
o Cnt - 一個噝兄械撓嫈底兞康漠斍爸怠