php編碼規范
php編碼規范
1. 介紹
1.1. 標準化的重要性
標準化問題在某些方面上讓每個人頭痛，讓人人都覺得大家處于同樣的境地。這有助于讓這些建議在許多的項目中不斷演進，許多公司花費了許多星期逐子字逐句的進行爭論。標準化不是特殊的個人風格，它對本地改良是完全開放的。
1.2. 優點
當一個項目嘗試著遵守公用的標準時，會有以下好處：
程序員可以了解任何代碼，弄清程序的狀況
新人可以很快的適應環境
防止新接觸php的人出于節省時間的需要，自創一套風格并養成終生的習慣
防止新接觸php的人一次次的犯同樣的錯誤
在一致的環境下，人們可以減少犯錯的機會
程序員們有了一致的敵人
1.3. 缺點
因為標準由一些不懂得php的人所制定，所以標準通常看上去很傻
因為標準跟我做的不一樣，所以標準通常看上去很傻
標準降低了創造力
標準在長期互相合作的人群中是沒有必要的
標準強迫太多的格式
1.4. 討論
許多項目的經驗能得出這樣的結論：采用編程標準可以使項目更加順利地完成。標準是成功的關鍵么？當然不。但它們可以幫助我們，而且我們需要我們能得到的所有的幫助！老實說，對一個細節標準的大部分爭論主要是源自自負思想。對一個合理的標準的很少決定能被說為是缺乏技術性的話，那只是口味的原因罷了。所以，要靈活的控制自負思想，記住，任何項目都取決于團隊合作的努力。
1.5. 解釋
1.5.1. 標準實施
首先應該在開發小組的內部找出所有的最重要的元素，也許標準對你的狀況還不夠恰當。它可能已經概括了 重要的問題，也可能還有人對其中的某些問題表示強烈的反對。無論在什么情況下，只要最后順利的話，人們將成熟的明白到這個標準是合理的，然后其他的程序員們也會發現它的合理性，并覺得帶著一些保留去遵循這一標準是值得的。如果沒有自愿的合作，可以制定需求：標準一定要經過代碼的檢驗。如果沒有檢驗的話，這個解決方案僅僅是一個建立在不精確的基礎上的一大群可笑的人。
1.5.2. 認同觀點
1. 這行不通；
2. 也許可行吧，但是它既不實用又無聊；
3. 這是真的，而且我也告訴過你啊；
4. 這個是我先想到的；
5. 本來就應該這樣。
如果您帶著否定的成見而來看待事物的話，請您保持開放的思想。你仍可以做出它是廢話的結論，但是做出結論的方法就是你必須要能夠接受不同的思想。請您給自己一點時間去做到它。
1.5.3. 項目的四個階段
1. 數據庫結構
2. 設計
3. 數據層
4. HTML層
2.命名規則
2.1. 合適的命名
命名是程序規劃的核心。古人相信只要知道一個人真正的名字就會獲得凌駕于那個人之上的不可思議的力量。只要你給事物想到正確的名字，就會給你以及后來的人帶來比代碼更強的力量。別笑！
名字就是事物在它所處的生態環境中一個長久而深遠的結果。總的來說，只有了解系統的程序員才能為系統取出最合適的名字。如果所有的命名都與其自然相適合，則關系清晰，含義可以推導得出，一般人的推想也能在意料之中。
如果你發覺你的命名只有少量能和其對應事物相匹配的話， 最好還是重新好好再看看你的設計吧。
2.2. 類命名
在為類（class ）命名前首先要知道它是什么。如果通過類名的提供的線索，你還是想不起這個類是什么的話，那么你的設計就還做的不夠好。
超過三個詞組成的混合名是容易造成系統各個實體間的混淆，再看看你的設計，嘗試使用（CRC Session card)看看該命名所對應的實體是否有著那么多的功用。
對于派生類的命名應該避免帶其父類名的誘惑，一個類的名字只與它自身有關，和它的父類叫什么無關。
有時后綴名是有用的，例如：如果你的系統使用了代理（agent ），那么就把某個部件命名為“下載代理”（DownloadAgent）用以真正的傳送信息。
2.3. 方法和函數命名
通常每個方法和函數都是執行一個動作的，所以對它們的命名應該清楚的說明它們是做什么的：用CheckForErrors()代替 ErrorCheck()，用DumpDataToFile()代替DataFile()。這么做也可以使功能和數據成為更可區分的物體。
有時后綴名是有用的:
Max - 含義為某實體所能賦予的最大值。
Cnt - 一個運行中的計數變量的當前值。
Key - 鍵值。
例如：RetryMax 表示最多重試次數，RetryCnt 表示當前重試次數。
有時前綴名是有用的：
Is - 含義為問一個關于某樣事物的問題。無論何時，當人們看到Is就會知道這是一個問題。
Get - 含義為取得一個數值。
Set - 含義為設定一個數值
例如：IsHitRetryLimit。
2.4. 縮寫詞不要全部使用大寫字母
無論如何，當遇到以下情況，你可以用首字母大寫其余字母小寫來代替全部使用大寫字母的方法來表示縮寫詞。
使用: GetHtmlStatistic.
不使用: GetHTMLStatistic.
理由
當命名含有縮略詞時，人們似乎有著非常不同的直覺。統一規定是最好，這樣一來，命名的含義就完全可以預知了。
舉個NetworkABCKey的例子，注意C是應該是ABC里面的C還是key里面的C，這個是很令人費解的。有些人不在意這些，其他人卻很討厭這樣。所以你會在不同的代碼里看到不同的規則，使得你不知道怎么去叫它。
例如
class FluidOz // 不要寫成 FluidOZ
class GetHtmlStatistic // 不要寫成 GetHTMLStatistic
2.5. 類命名
使用大寫字母作為詞的分隔，其他的字母均使用小寫
名字的首字母使用大寫
不要使用下劃線('_')
理由
根據很多的命名方式，大部分人認為這樣是最好的方式。
例如
class NameOneTwo
class Name
2.6. 類庫命名
目前命名空間正在越來越廣泛的被采用，以避免不同廠商和團體類庫間的類名沖突。
當尚未采用命名空間的時候，為了避免類名沖突，一般的做法是在類名前加上獨特的前綴，兩個字符就可以了，當然多用一些會更好。
例如
John Johnson的數據結構類庫可以用Jj做為前綴，如下：
class JjLinkList
{
}
另一種折中方式是建立包含類庫目錄（事實上Java也是這么做的），以不通的目錄代表不同的命名空間。
例如
Microsoft的數據庫相關類庫可以在：
/classes/com/Microsoft/ Database/DbConn.php
Apache的數據庫相關類庫可在：
/classes/org/apache/Database/DbConn.php
2.7. 方法命名
采用與類命名一致的規則
理由
使用所有不同規則的大部分人發現這是最好的折衷辦法。
例如
class NameOneTwo
{
function DoIt() {};
function HandleError() {};
}
2.8. 類屬性命名
屬性命名應該以字符‘m’為前綴。
前綴‘m’后采用于類命名一致的規則。
‘m’總是在名字的開頭起修飾作用，就像以‘r’開頭表示引用一樣。
理由
前綴'm'防止類屬性和方法名發生任何沖突。你的方法名和屬性名經常會很類似，特別是存取元素。
例如
class NameOneTwo
{
function VarAbc() {};
function ErrorNumber() {};
var $mVarAbc;
var $mErrorNumber;
var $mrName;
}
2.9. 方法中參數命名
第一個字符使用小寫字母。
在首字符后的所有字都按照類命名規則首字符大寫。
理由
可以區分方法中的一般變量。
你可以使用與類名相似的名稱而不至于產生重名沖突。
例如
class NameOneTwo
{
function StartYourEngines(
&$rSomeEngine,
&$rAnotherEngine);
}
2.10. 變量命名
所有字母都使用小寫
使用'_'作為每個詞的分界。
理由
通過這一途徑，代碼中變量的作用域是清晰的。
所有的變量在代碼中都看起來不同，容易辨認。
例如
function HandleError($errorNumber)
{
$error = OsErr($errorNumber);
$time_of_error = OsErr->GetTimeOfError();
$error_processor = OsErr->GetErrorProcessor();
}
2.11. 引用變量和函數返回引用
引用必須帶‘r’前綴
理由
使得類型不同的變量容易辨認
它可以確定哪個方法返回可更改對象，哪個方法返回不可更改對象。
例如
class Test
{
var mrStatus;
function DoSomething(&$rStatus) {};
function &rStatus() {};
}
2.12. 全局變量
全局變量應該帶前綴‘g’。
理由
知道一個變量的作用域是非常重要的。
例如
global $gLog;
global &$grLog;
2.13. 定義命名 / 全局常量
全局常量用'_'分隔每個單詞。
理由
這是命名全局常量的傳統。你要注意不要與其它的定義相沖突。
例如
define("A_GLOBAL_CONSTANT", "Hello world!");
2.14. 靜態變量
靜態變量應該帶前綴‘s’。
理由
知道一個變量的作用域是非常重要的。
例如
function test()
{
static $msStatus = 0;
}
2.15. 函數命名
函數名字采用C GNU的慣例，所有的字母使用小寫字母，使用'_'分割單詞。
理由
這樣可以更易于區分相關聯的類名。
例如
function some_bloody_function()
{
}
2.16. 錯誤返回檢測規則
檢查所有的系統調用的錯誤信息，除非你要忽略錯誤。
為每條系統錯誤消息定義好系統錯誤文本以便include。
3. 書寫規則
3.1. 大括號 {} 規則
在三種主要的大括號放置規則中，有兩種是可以接受的，如下的第一種是最好的：
將大括號放置在關鍵詞下方的同列處：
if ($condition)
{
while ($condition)
{
...
...
}
}
傳統的UNIX的括號規則是，首括號與關鍵詞同行，尾括號與關鍵字同列：
if ($condition) {
while ($condition) {
...
...
}
}
理由
引起劇烈爭論的非原則的問題可通過折衷的辦法解決，兩種方法任意一種都是可以接受的，然而對于大多數人來說更喜歡第一種。原因就是心理研究學習范疇的東西了。
對于更喜歡第一種還有著更多的原因。如果您使用的字符編輯器支持括號匹配功能的話（例如vi），最重要的就是有一個好的樣式。為什么？我們說當你有一大塊的程序而且想知道這一大塊程序是在哪兒結束的話。你先移到開始的括號，按下按鈕編輯器就會找到與之對應的結束括號，例如：
if ($very_long_condition && $second_very_long_condition)
{
...
}
else if (...)
{
...
}
從一個程序塊移動到另一個程序塊只需要用光標和你的括號匹配鍵就可以了，不需找匹配的括號。
3.2. 縮進/制表符/空格 規則
使用制表符縮進。
使用三到四個空格為每層次縮進。
不再使用只要一有需要就縮排的方法。對于最大縮進層數，并沒有一個固定的規矩，假如縮進層數大于四或者五層的時候，你可以考慮著將代碼因數分解(factoring out code)。
理由
許多編程者支持制表符。
當人們使用差異太大的制表符標準的話，會使閱讀代碼變得很費力。
如此多的人愿意限定最大的縮進層數，它通常從未被看作是一件工作。我們相信程序員們會明智的選擇嵌套的深度。
例如
function func()
{
if (something bad)
{
if (another thing bad)
{
while (more input)
{
}
}
}
}
3.3. 小括號、關鍵詞和函數 規則
不要把小括號和關鍵詞緊貼在一起，要用空格隔開它們。
不要把小括號和函數名緊貼在一起。
除非必要，不要在Return返回語句中使用小括號。
理由
關鍵字不是函數。如果小括號緊貼著函數名和關鍵字，二者很容易被看成是一體的。
例如
if (condition)
{
}
while (condition)
{
}
strcmp($s, $s1);
return 1;
3.4. 別在對象架構函數中做實際的工作
別在對象架構構造函數中做實際的工作， 構造函數應該包含變量的初始化和（或）不會發生失敗的操作。
理由
構造不能返回錯誤 。
例如
class Device
{
function Device() { /* initialize and other stuff */ }
function Open() { return FAIL; }
};
$dev = new Device;
if (FAIL == $dev->Open()) exit(1);
3.5. If Then Else 格式
布局
這由程序員決定。不同的花括號樣式會產生些微不同的樣觀。一個通用方式是：
if (條件1) // 注釋
{
}
else if (條件2) // 注釋
{
}
else // 注釋
{
}
如果你有用到else if 語句的話，通常最好有一個else塊以用于處理未處理到的其他情況。可以的話放一個記錄信息注釋在else處，即使在else沒有任何的動作。
條件格式總是將恒量放在等號/不等號的左邊，
例如：
if ( 6 == $errorNum ) ...
一個原因是假如你在等式中漏了一個等號，語法檢查器會為你報錯。第二個原因是你能立刻找到數值而不是在你的表達式的末端找到它。需要一點時間來習慣這個格式，但是它確實很有用。
3.6. switch 格式
當一個case塊處理后，直接轉到下一個case塊處理，在這個case塊的最后應該加上注釋。
default case總應該存在，它應該不被到達，然而如果到達了就會觸發一個錯誤。
如果你要創立一個變量，那就把所有的代碼放在塊中。
例如
switch (...)
{
case 1:
...
// FALL THROUGH
case 2:
{
$v = get_week_number();
...
}
break;
default:
}
3.7. continue,break 和 ? 的使用
3.7.1. Continue 和 Break
Continue 和 break 其實是變相的隱蔽的 goto方法。
Continue 和 break 像 goto 一樣，它們在代碼中是有魔力的，所以要節儉（盡可能少）的使用它們。使用了這一簡單的魔法，由于一些未公開的原因，讀者將會被定向到只有上帝才知道的地方去。
Continue有兩個主要的問題：
它可以繞過測試條件。
它可以繞過等/不等表達式。
看看下面的例子，考慮一下問題都在哪兒發生：
while (TRUE)
{
...
// A lot of code
...
if (/* some condition */) {
continue;
}
...
// A lot of code
...
if ( $i++ > STOP_VALUE) break;
}
注意："A lot of code"是必須的，這是為了讓程序員們不能那么容易的找出錯誤。
通過以上的例子，我們可以得出更進一步的規則：continue 和 break 混合使用是引起災難的正確方法。
3.7.2. ?:
麻煩在于人們往往試著在 ? 和 : 之間塞滿了許多的代碼。以下的是一些清晰的連接規則：
把條件放在括號內以使它和其他的代碼相分離。
如果可能的話，動作可以用簡單的函數。
把所做的動作，“?”，“:”放在不同的行，除非他們可以清楚的放在同一行。
例如
(condition) ? funct1() : func2();
or
(condition)
? long statement
: another long statement;
3.8. 聲明塊的定位
聲明代碼塊需要對齊。
理由
清晰。
變量初始化的類似代碼塊應該列表。
&應靠近類型，而不是變量名。
例如
var $mDate
var& $mrDate
var& $mrName
var $mName
$mDate = 0;
$mrDate = NULL;
$mrName = 0;
$mName = NULL;
3.9. 每行一個語句
除非這些語句有很密切的聯系，否則每行只寫一個語句。
3.10. 短方法
方法代碼要限制在一頁內。
3.11. 記錄所有的空語句
總是記錄下for或者是while的空塊語句，以便清楚的知道該段代碼是漏掉了，還是故意不寫的。
while ($dest++ = $src++)
; // VOID
3.12. 不要采用缺省方法測試非零值
不要采用缺省值測試非零值，也就是使用：
if (FAIL != f())
比下面的方法好：
if (f())
即使 FAIL 可以含有 0 值 ，也就是PHP認為false的表示。在某人決定用-1代替0作為失敗返回值的時候，一個顯式的測試就可以幫助你了。就算是比較值不會變化也應該使用顯式的比較；例如：if (!($bufsize % strlen($str)))應該寫成：if (($bufsize % strlen($str)) == 0)以表示測試的數值（不是布爾）型。一個經常出問題的地方就是使用strcmp來測試一個字符等式，結果永遠也不會等于缺省值。
非零測試采用基于缺省值的做法，那么其他函數或表達式就會受到以下的限制:
只能返回0表示失敗，不能為/有其他的值。
命名以便讓一個真(true)的返回值是絕對顯然的，調用函數IsValid()而不是Checkvalid()。
3.13. 布爾邏輯類型
大部分函數在FALSE的時候返回0，但是發揮非0值就代表TRUE，因而不要用1（TRUE，YES，諸如此類）等式檢測一個布爾值，應該用0（FALSE，NO，諸如此類）的不等式來代替：
if (TRUE == func()) { ...
應該寫成：
if (FALSE != func()) { ...
3.14. 通常避免嵌入式的賦值
有時候在某些地方我們可以看到嵌入式賦值的語句，那些結構不是一個比較好的少冗余，可讀性強的方法。
while ($a != ($c = getchar()))
{
process the character
}
++和--操作符類似于賦值語句。因此，出于許多的目的，在使用函數的時候會產生副作用。使用嵌入式賦值提高運行時性能是可能的。無論怎樣，程序員在使用嵌入式賦值語句時需要考慮在增長的速度和減少的可維護性兩者間加以權衡。例如：
a = b + c;
d = a + r;
不要寫成：
d = (a = b + c) + r;
雖然后者可以節省一個周期。但在長遠來看，隨著程序的維護費用漸漸增長，程序的編寫者對代碼漸漸遺忘，就會減少在成熟期的最優化所得。
4. 幫助與共享
4.1. 重用您和其他人的艱苦工作
跨工程的重用在沒有一個通用結構的情況下幾乎是不可能的。對象符合他們現有的服務需求，不同的過程有著不同的服務需求環境，這使對象重用變得很困難。
開發一個通用結構需要預先花費許多的努力來設計。當努力不成功的時候，無論出于什么原因，有幾種辦法推薦使用：
4.2. 請教！給群組發Email求助
這個簡單的方法很少被使用。因為有些程序員們覺得如果他向其他人求助，會顯得自己水平低，這多傻啊!做新的有趣的工作，不要一遍又一遍的做別人已經做過的東西。
如果你需要某些事項的源代碼，如果已經有某人做過的話，就向群組發email求助。結果會很驚喜哦！
在許多大的群組中，個人往往不知道其他人在干什么。你甚至可以發現某人在找一些東西做，并且自愿為你寫代碼，如果人們在一起工作，外面就總有一個金礦。
4.3. 告訴！當你在做事的時候，把它告訴所有人
如果你做了什么可重用的東西的話，讓其他人知道。別害羞，也不要為了保護自豪感而把你的工作成果藏起來。一旦養成共享工作成果的習慣，每個人都會獲得更多。
4.4. 小型代碼庫
對于代碼重用，一個常見的問題就是人們不從他們做過的代碼中做庫。一個可重用的類可能正隱蔽在一個程序目錄并且決不會有被分享的激動，因為程序員不會把類分拆出來加入庫中。
這樣的其中一個原因就是人們不喜歡做一個小庫，對小庫有一些不正確感覺。把這樣的感覺克服掉吧，電腦才不關心你有多少個庫呢。
如果你有一些代碼可以重用，而且不能放入一個已經存在的庫中，那么就做一個新的庫吧。如果人們真的考慮重用的話，庫不會在很長的一段時間里保持那么小的。
4.5. 知識庫
很多公司不清楚現有什么代碼可用，而且大多數程序員仍然沒有通過溝通他們已經做過了什么，或者一直在詢問現存什么代碼可用。解決這個的方法是有一個可用的知識庫。
理想的情況是，程序員可以到一個WEB頁，瀏覽或者查詢打包的知識庫列表，找到他們所要的。建立一個程序員可以自動維護的知識庫系統，是一個很不錯的做法。如果有一個專門的管理員來負責維護這個知識庫，那當然更好。
另一種方法是自動的從代碼中產生知識庫的做法。把通用的類、方法和標頭（subsystem headers）作為手冊或者是知識庫的一個條目。
5. 書寫注釋
5.1. 講一個故事
把你的注釋當作描述系統的一個故事。并且使得你的注釋能被機器解析后，以固定的格式放到手冊中去。類的注釋是故事的一部分，方法的名稱、方法的注釋、方法的實現也是故事一部分。所有的這些部分編織在一起，使得人們在以后的時間里能夠準確的知道你干了什么，為什么這么做。
5.2. 歸檔注釋
注釋的要歸檔才有意義，否則，假如在一個地方放一條注釋描述你做了什么選擇和你為什么這么做，只有考古學家才能發現這是最有用的信息。（如何歸檔另行規范）
5.3. 注釋結構
工程的每部分都有特定的注釋結構。 程序中的注釋，這里給出示例作為規范，注釋中以 * @ 為關鍵字的開始，以:為注釋關鍵字結尾。
5.3.1. 預定義關鍵字
關鍵字 含義
Purpose 表示類、屬性、方法要做些什么或者什么含義。
Package Name 類名
Author 作者
Modifications 修改記錄（編號規則為“No”＋日期＋“－”＋序號）
See 參考
Method Name 方法名
Parameter 參數名（包括類型）
Return 返回值（包括類型）
Attribute/Variable Name 屬性/變量名
Type 屬性/變量類型
5.3.2. 類的注釋
/**
* @ Purpose:
* 訪問數據庫的類，以ODBC作為通用訪問接口
* @Package Name: Database
* @Author: Forrest Gump gump@crtvu.edu.cn
* @Modifications:
* No20020523-100:
* odbc_fetch_into()參數位置第二和第三個位置調換
* John Johnson John@crtvu.edu.cn
* @See: (參照)
*/
class Database
{
……
}
5.3.3. 方法注釋
/**
* @Purpose:
* 執行一次查詢
* @Method Name: Query()
* @Parameter: string $queryStr SQL查詢字符串
* @Return: mixed 查詢返回值（結果集對象）
*/
function（$queryStr）{……}
5.3.4.屬性或變量注釋
/**
* @Purpose:
* 數據庫連接用戶名
* @Attribute/Variable Name: mDbUserName
* @Type: string
*/
var mDbUserName;
5.3.5. if (0)來注釋外部代碼塊
有時需要注釋大段的測試代碼，最簡單的方法就是使用if (0)塊：
function example()
{
great looking code
if (0) {
lots of code
}
more code
}
你不能使用/**/，因為注釋內部不能包含注釋，而大段的程序中可以包含注釋。
5.3.6. 目錄文檔
所有的目錄下都需要具有README文檔，其中包括：
該目錄的功能及其包含內容
一個對每一文件的在線說明（帶有link），每一個說明通常還應該提取文件標頭的一些屬性名字。
包括設置、使用說明
指導人們如何連接相關資源：
源文件索引
在線文檔
紙文檔
設計文檔
其他對讀者有幫助的東西
考慮一下，當每個原有的工程人員走了，在6個月之內來的一個新人，那個孤獨受驚嚇的探險者通過整個工程的源代碼目錄樹，閱讀說明文件，源文件的標頭說明等等做為地圖，他應該有能力穿越整個工程。
6. 其他
采用面向對象的設計方法；
理由
毫無疑問這是最接近人們自然思維的方法，可能前期會覺得沒有直接書寫來得快，能否試著保留自己的看法？好戲在后頭！
類的定義采用一個文件一個類，并且類名和文件名相同；
理由
越來越多的人接受了這種做法
事實證明這種方法使得項目的邏輯結構更清晰
類定義文件中，定義體之外不得出現諸如echo、print等輸出語句；
理由
出現這樣的語句，應該當做出現bug來看。
輸出網頁的頁面不出現SQL語句
理由
這是n層結構的編程思想所致，每層的任務不同，雖然可以越權行使，可能這樣很快捷，但我們不贊成這么干。
進行SQL執行的數據必須進行有效性檢測
特殊符號：
對于MS SQL Server，’%_[ ] 這些符號都是在書寫SQL語句中的特殊含義字符，在SQL執行前需要對這些字符進行處理。
腳本符號：
對于PHP腳本標記，如，在進入數據庫前需要檢測處理。
理由
這是數據庫編程的一個約定，很多參考書上也是這么說，這里需要強調一下。
在HTML網頁中盡量不要穿插PHP代碼
循環代碼和純粹變量輸出（類似于）除外。
理由
需要說明的是我們工作的上游，頁面設計者的工作，假如在頁面中穿插代碼，將破壞結構，這應當是我們需要避免的。
在這里的PHP代碼只負責顯示，多余的代碼顯然是不應該的。
沒有含義的數字
一個在源代碼中使用了的赤裸裸的數字是不可思議的數字，因為包括作者，在三個月內，沒人它的含義。例如：
if (22 == $foo) { start_thermo_nuclear_war(); }
else if (19 == $foo) { refund_lotso_money(); }
else if (16 == $foo) { infinite_loop(); }
else { cry_cause_im_lost(); }
在上例中22和19的含義是什么呢？如果一個數字改變了，或者這些數字只是簡單的錯誤，你會怎么想？
使用不可思議的數字是該程序員是業余運動員的重要標志，這樣的程序員從來沒有在團隊環境中工作過，又或者是為了維持代碼而不得不做的，否則他們永遠不會做這樣的事。
你應該用define()來給你想表示某樣東西的數值一個真正的名字，而不是采用赤裸裸的數字，例如：
define(" RESIDENT_WENT_CRAZY", "22");
define("WE_GOOFED", "19");
define("THEY_DIDNT_PAY", "16");
if (PRESIDENT_WENT_CRAZY == $foo) { start_thermo_nuclear_war(); }
else if (WE_GOOFED == $foo) { refund_lotso_money(); }
else if (THEY_DIDNT_PAY == $foo) { infinite_loop(); }
else { happy_days_i_know_why_im_here(); }
現在不是變得更好了么？
7. PHP文件擴展名
常見的PHP文件的擴展名有：html, .php, .php3, .php4, .phtml, .inc, .class...
這里我們約定：
所有瀏覽者可見頁面使用.html
所有類、函數庫文件使用.php
理由
擴展名描述的是那種數據是用戶將會收到的。PHP是解釋為HTML的。
8. PHP代碼標記
統一使用，只輸出變量時
1. 介紹
1.1. 標準化的重要性
標準化問題在某些方面上讓每個人頭痛，讓人人都覺得大家處于同樣的境地。這有助于讓這些建議在許多的項目中不斷演進，許多公司花費了許多星期逐子字逐句的進行爭論。標準化不是特殊的個人風格，它對本地改良是完全開放的。
1.2. 優點
當一個項目嘗試著遵守公用的標準時，會有以下好處：
程序員可以了解任何代碼，弄清程序的狀況
新人可以很快的適應環境
防止新接觸php的人出于節省時間的需要，自創一套風格并養成終生的習慣
防止新接觸php的人一次次的犯同樣的錯誤
在一致的環境下，人們可以減少犯錯的機會
程序員們有了一致的敵人
1.3. 缺點
因為標準由一些不懂得php的人所制定，所以標準通常看上去很傻
因為標準跟我做的不一樣，所以標準通常看上去很傻
標準降低了創造力
標準在長期互相合作的人群中是沒有必要的
標準強迫太多的格式
1.4. 討論
許多項目的經驗能得出這樣的結論：采用編程標準可以使項目更加順利地完成。標準是成功的關鍵么？當然不。但它們可以幫助我們，而且我們需要我們能得到的所有的幫助！老實說，對一個細節標準的大部分爭論主要是源自自負思想。對一個合理的標準的很少決定能被說為是缺乏技術性的話，那只是口味的原因罷了。所以，要靈活的控制自負思想，記住，任何項目都取決于團隊合作的努力。
1.5. 解釋
1.5.1. 標準實施
首先應該在開發小組的內部找出所有的最重要的元素，也許標準對你的狀況還不夠恰當。它可能已經概括了 重要的問題，也可能還有人對其中的某些問題表示強烈的反對。無論在什么情況下，只要最后順利的話，人們將成熟的明白到這個標準是合理的，然后其他的程序員們也會發現它的合理性，并覺得帶著一些保留去遵循這一標準是值得的。如果沒有自愿的合作，可以制定需求：標準一定要經過代碼的檢驗。如果沒有檢驗的話，這個解決方案僅僅是一個建立在不精確的基礎上的一大群可笑的人。
1.5.2. 認同觀點
1. 這行不通；
2. 也許可行吧，但是它既不實用又無聊；
3. 這是真的，而且我也告訴過你啊；
4. 這個是我先想到的；
5. 本來就應該這樣。
如果您帶著否定的成見而來看待事物的話，請您保持開放的思想。你仍可以做出它是廢話的結論，但是做出結論的方法就是你必須要能夠接受不同的思想。請您給自己一點時間去做到它。
1.5.3. 項目的四個階段
1. 數據庫結構
2. 設計
3. 數據層
4. HTML層
2.命名規則
2.1. 合適的命名
命名是程序規劃的核心。古人相信只要知道一個人真正的名字就會獲得凌駕于那個人之上的不可思議的力量。只要你給事物想到正確的名字，就會給你以及后來的人帶來比代碼更強的力量。別笑！
名字就是事物在它所處的生態環境中一個長久而深遠的結果。總的來說，只有了解系統的程序員才能為系統取出最合適的名字。如果所有的命名都與其自然相適合，則關系清晰，含義可以推導得出，一般人的推想也能在意料之中。
如果你發覺你的命名只有少量能和其對應事物相匹配的話， 最好還是重新好好再看看你的設計吧。
2.2. 類命名
在為類（class ）命名前首先要知道它是什么。如果通過類名的提供的線索，你還是想不起這個類是什么的話，那么你的設計就還做的不夠好。
超過三個詞組成的混合名是容易造成系統各個實體間的混淆，再看看你的設計，嘗試使用（CRC Session card)看看該命名所對應的實體是否有著那么多的功用。
對于派生類的命名應該避免帶其父類名的誘惑，一個類的名字只與它自身有關，和它的父類叫什么無關。
有時后綴名是有用的，例如：如果你的系統使用了代理（agent ），那么就把某個部件命名為“下載代理”（DownloadAgent）用以真正的傳送信息。
2.3. 方法和函數命名
通常每個方法和函數都是執行一個動作的，所以對它們的命名應該清楚的說明它們是做什么的：用CheckForErrors()代替 ErrorCheck()，用DumpDataToFile()代替DataFile()。這么做也可以使功能和數據成為更可區分的物體。
有時后綴名是有用的:
Max - 含義為某實體所能賦予的最大值。
Cnt - 一個運行中的計數變量的當前值。
Key - 鍵值。
例如：RetryMax 表示最多重試次數，RetryCnt 表示當前重試次數。
有時前綴名是有用的：
Is - 含義為問一個關于某樣事物的問題。無論何時，當人們看到Is就會知道這是一個問題。
Get - 含義為取得一個數值。
Set - 含義為設定一個數值
例如：IsHitRetryLimit。
2.4. 縮寫詞不要全部使用大寫字母
無論如何，當遇到以下情況，你可以用首字母大寫其余字母小寫來代替全部使用大寫字母的方法來表示縮寫詞。
使用: GetHtmlStatistic.
不使用: GetHTMLStatistic.
理由
當命名含有縮略詞時，人們似乎有著非常不同的直覺。統一規定是最好，這樣一來，命名的含義就完全可以預知了。
舉個NetworkABCKey的例子，注意C是應該是ABC里面的C還是key里面的C，這個是很令人費解的。有些人不在意這些，其他人卻很討厭這樣。所以你會在不同的代碼里看到不同的規則，使得你不知道怎么去叫它。
例如
class FluidOz // 不要寫成 FluidOZ
class GetHtmlStatistic // 不要寫成 GetHTMLStatistic
2.5. 類命名
使用大寫字母作為詞的分隔，其他的字母均使用小寫
名字的首字母使用大寫
不要使用下劃線('_')
理由
根據很多的命名方式，大部分人認為這樣是最好的方式。
例如
class NameOneTwo
class Name
2.6. 類庫命名
目前命名空間正在越來越廣泛的被采用，以避免不同廠商和團體類庫間的類名沖突。
當尚未采用命名空間的時候，為了避免類名沖突，一般的做法是在類名前加上獨特的前綴，兩個字符就可以了，當然多用一些會更好。
例如
John Johnson的數據結構類庫可以用Jj做為前綴，如下：
class JjLinkList
{
}
另一種折中方式是建立包含類庫目錄（事實上Java也是這么做的），以不通的目錄代表不同的命名空間。
例如
Microsoft的數據庫相關類庫可以在：
/classes/com/Microsoft/ Database/DbConn.php
Apache的數據庫相關類庫可在：
/classes/org/apache/Database/DbConn.php
2.7. 方法命名
采用與類命名一致的規則
理由
使用所有不同規則的大部分人發現這是最好的折衷辦法。
例如
class NameOneTwo
{
function DoIt() {};
function HandleError() {};
}
2.8. 類屬性命名
屬性命名應該以字符‘m’為前綴。
前綴‘m’后采用于類命名一致的規則。
‘m’總是在名字的開頭起修飾作用，就像以‘r’開頭表示引用一樣。
理由
前綴'm'防止類屬性和方法名發生任何沖突。你的方法名和屬性名經常會很類似，特別是存取元素。
例如
class NameOneTwo
{
function VarAbc() {};
function ErrorNumber() {};
var $mVarAbc;
var $mErrorNumber;
var $mrName;
}
2.9. 方法中參數命名
第一個字符使用小寫字母。
在首字符后的所有字都按照類命名規則首字符大寫。
理由
可以區分方法中的一般變量。
你可以使用與類名相似的名稱而不至于產生重名沖突。
例如
class NameOneTwo
{
function StartYourEngines(
&$rSomeEngine,
&$rAnotherEngine);
}
2.10. 變量命名
所有字母都使用小寫
使用'_'作為每個詞的分界。
理由
通過這一途徑，代碼中變量的作用域是清晰的。
所有的變量在代碼中都看起來不同，容易辨認。
例如
function HandleError($errorNumber)
{
$error = OsErr($errorNumber);
$time_of_error = OsErr->GetTimeOfError();
$error_processor = OsErr->GetErrorProcessor();
}
2.11. 引用變量和函數返回引用
引用必須帶‘r’前綴
理由
使得類型不同的變量容易辨認
它可以確定哪個方法返回可更改對象，哪個方法返回不可更改對象。
例如
class Test
{
var mrStatus;
function DoSomething(&$rStatus) {};
function &rStatus() {};
}
2.12. 全局變量
全局變量應該帶前綴‘g’。
理由
知道一個變量的作用域是非常重要的。
例如
global $gLog;
global &$grLog;
2.13. 定義命名 / 全局常量
全局常量用'_'分隔每個單詞。
理由
這是命名全局常量的傳統。你要注意不要與其它的定義相沖突。
例如
define("A_GLOBAL_CONSTANT", "Hello world!");
2.14. 靜態變量
靜態變量應該帶前綴‘s’。
理由
知道一個變量的作用域是非常重要的。
例如
function test()
{
static $msStatus = 0;
}
2.15. 函數命名
函數名字采用C GNU的慣例，所有的字母使用小寫字母，使用'_'分割單詞。
理由
這樣可以更易于區分相關聯的類名。
例如
function some_bloody_function()
{
}
2.16. 錯誤返回檢測規則
檢查所有的系統調用的錯誤信息，除非你要忽略錯誤。
為每條系統錯誤消息定義好系統錯誤文本以便include。
3. 書寫規則
3.1. 大括號 {} 規則
在三種主要的大括號放置規則中，有兩種是可以接受的，如下的第一種是最好的：
將大括號放置在關鍵詞下方的同列處：
if ($condition)
{
while ($condition)
{
...
...
}
}
傳統的UNIX的括號規則是，首括號與關鍵詞同行，尾括號與關鍵字同列：
if ($condition) {
while ($condition) {
...
...
}
}
理由
引起劇烈爭論的非原則的問題可通過折衷的辦法解決，兩種方法任意一種都是可以接受的，然而對于大多數人來說更喜歡第一種。原因就是心理研究學習范疇的東西了。
對于更喜歡第一種還有著更多的原因。如果您使用的字符編輯器支持括號匹配功能的話（例如vi），最重要的就是有一個好的樣式。為什么？我們說當你有一大塊的程序而且想知道這一大塊程序是在哪兒結束的話。你先移到開始的括號，按下按鈕編輯器就會找到與之對應的結束括號，例如：
if ($very_long_condition && $second_very_long_condition)
{
...
}
else if (...)
{
...
}
從一個程序塊移動到另一個程序塊只需要用光標和你的括號匹配鍵就可以了，不需找匹配的括號。
3.2. 縮進/制表符/空格 規則
使用制表符縮進。
使用三到四個空格為每層次縮進。
不再使用只要一有需要就縮排的方法。對于最大縮進層數，并沒有一個固定的規矩，假如縮進層數大于四或者五層的時候，你可以考慮著將代碼因數分解(factoring out code)。
理由
許多編程者支持制表符。
當人們使用差異太大的制表符標準的話，會使閱讀代碼變得很費力。
如此多的人愿意限定最大的縮進層數，它通常從未被看作是一件工作。我們相信程序員們會明智的選擇嵌套的深度。
例如
function func()
{
if (something bad)
{
if (another thing bad)
{
while (more input)
{
}
}
}
}
3.3. 小括號、關鍵詞和函數 規則
不要把小括號和關鍵詞緊貼在一起，要用空格隔開它們。
不要把小括號和函數名緊貼在一起。
除非必要，不要在Return返回語句中使用小括號。
理由
關鍵字不是函數。如果小括號緊貼著函數名和關鍵字，二者很容易被看成是一體的。
例如
if (condition)
{
}
while (condition)
{
}
strcmp($s, $s1);
return 1;
3.4. 別在對象架構函數中做實際的工作
別在對象架構構造函數中做實際的工作， 構造函數應該包含變量的初始化和（或）不會發生失敗的操作。
理由
構造不能返回錯誤 。
例如
class Device
{
function Device() { /* initialize and other stuff */ }
function Open() { return FAIL; }
};
$dev = new Device;
if (FAIL == $dev->Open()) exit(1);
3.5. If Then Else 格式
布局
這由程序員決定。不同的花括號樣式會產生些微不同的樣觀。一個通用方式是：
if (條件1) // 注釋
{
}
else if (條件2) // 注釋
{
}
else // 注釋
{
}
如果你有用到else if 語句的話，通常最好有一個else塊以用于處理未處理到的其他情況。可以的話放一個記錄信息注釋在else處，即使在else沒有任何的動作。
條件格式總是將恒量放在等號/不等號的左邊，
例如：
if ( 6 == $errorNum ) ...
一個原因是假如你在等式中漏了一個等號，語法檢查器會為你報錯。第二個原因是你能立刻找到數值而不是在你的表達式的末端找到它。需要一點時間來習慣這個格式，但是它確實很有用。
3.6. switch 格式
當一個case塊處理后，直接轉到下一個case塊處理，在這個case塊的最后應該加上注釋。
default case總應該存在，它應該不被到達，然而如果到達了就會觸發一個錯誤。
如果你要創立一個變量，那就把所有的代碼放在塊中。
例如
switch (...)
{
case 1:
...
// FALL THROUGH
case 2:
{
$v = get_week_number();
...
}
break;
default:
}
3.7. continue,break 和 ? 的使用
3.7.1. Continue 和 Break
Continue 和 break 其實是變相的隱蔽的 goto方法。
Continue 和 break 像 goto 一樣，它們在代碼中是有魔力的，所以要節儉（盡可能少）的使用它們。使用了這一簡單的魔法，由于一些未公開的原因，讀者將會被定向到只有上帝才知道的地方去。
Continue有兩個主要的問題：
它可以繞過測試條件。
它可以繞過等/不等表達式。
看看下面的例子，考慮一下問題都在哪兒發生：
while (TRUE)
{
...
// A lot of code
...
if (/* some condition */) {
continue;
}
...
// A lot of code
...
if ( $i++ > STOP_VALUE) break;
}
注意："A lot of code"是必須的，這是為了讓程序員們不能那么容易的找出錯誤。
通過以上的例子，我們可以得出更進一步的規則：continue 和 break 混合使用是引起災難的正確方法。
3.7.2. ?:
麻煩在于人們往往試著在 ? 和 : 之間塞滿了許多的代碼。以下的是一些清晰的連接規則：
把條件放在括號內以使它和其他的代碼相分離。
如果可能的話，動作可以用簡單的函數。
把所做的動作，“?”，“:”放在不同的行，除非他們可以清楚的放在同一行。
例如
(condition) ? funct1() : func2();
or
(condition)
? long statement
: another long statement;
3.8. 聲明塊的定位
聲明代碼塊需要對齊。
理由
清晰。
變量初始化的類似代碼塊應該列表。
&應靠近類型，而不是變量名。
例如
var $mDate
var& $mrDate
var& $mrName
var $mName
$mDate = 0;
$mrDate = NULL;
$mrName = 0;
$mName = NULL;
3.9. 每行一個語句
除非這些語句有很密切的聯系，否則每行只寫一個語句。
3.10. 短方法
方法代碼要限制在一頁內。
3.11. 記錄所有的空語句
總是記錄下for或者是while的空塊語句，以便清楚的知道該段代碼是漏掉了，還是故意不寫的。
while ($dest++ = $src++)
; // VOID
3.12. 不要采用缺省方法測試非零值
不要采用缺省值測試非零值，也就是使用：
if (FAIL != f())
比下面的方法好：
if (f())
即使 FAIL 可以含有 0 值 ，也就是PHP認為false的表示。在某人決定用-1代替0作為失敗返回值的時候，一個顯式的測試就可以幫助你了。就算是比較值不會變化也應該使用顯式的比較；例如：if (!($bufsize % strlen($str)))應該寫成：if (($bufsize % strlen($str)) == 0)以表示測試的數值（不是布爾）型。一個經常出問題的地方就是使用strcmp來測試一個字符等式，結果永遠也不會等于缺省值。
非零測試采用基于缺省值的做法，那么其他函數或表達式就會受到以下的限制:
只能返回0表示失敗，不能為/有其他的值。
命名以便讓一個真(true)的返回值是絕對顯然的，調用函數IsValid()而不是Checkvalid()。
3.13. 布爾邏輯類型
大部分函數在FALSE的時候返回0，但是發揮非0值就代表TRUE，因而不要用1（TRUE，YES，諸如此類）等式檢測一個布爾值，應該用0（FALSE，NO，諸如此類）的不等式來代替：
if (TRUE == func()) { ...
應該寫成：
if (FALSE != func()) { ...
3.14. 通常避免嵌入式的賦值
有時候在某些地方我們可以看到嵌入式賦值的語句，那些結構不是一個比較好的少冗余，可讀性強的方法。
while ($a != ($c = getchar()))
{
process the character
}
++和--操作符類似于賦值語句。因此，出于許多的目的，在使用函數的時候會產生副作用。使用嵌入式賦值提高運行時性能是可能的。無論怎樣，程序員在使用嵌入式賦值語句時需要考慮在增長的速度和減少的可維護性兩者間加以權衡。例如：
a = b + c;
d = a + r;
不要寫成：
d = (a = b + c) + r;
雖然后者可以節省一個周期。但在長遠來看，隨著程序的維護費用漸漸增長，程序的編寫者對代碼漸漸遺忘，就會減少在成熟期的最優化所得。
4. 幫助與共享
4.1. 重用您和其他人的艱苦工作
跨工程的重用在沒有一個通用結構的情況下幾乎是不可能的。對象符合他們現有的服務需求，不同的過程有著不同的服務需求環境，這使對象重用變得很困難。
開發一個通用結構需要預先花費許多的努力來設計。當努力不成功的時候，無論出于什么原因，有幾種辦法推薦使用：
4.2. 請教！給群組發Email求助
這個簡單的方法很少被使用。因為有些程序員們覺得如果他向其他人求助，會顯得自己水平低，這多傻啊!做新的有趣的工作，不要一遍又一遍的做別人已經做過的東西。
如果你需要某些事項的源代碼，如果已經有某人做過的話，就向群組發email求助。結果會很驚喜哦！
在許多大的群組中，個人往往不知道其他人在干什么。你甚至可以發現某人在找一些東西做，并且自愿為你寫代碼，如果人們在一起工作，外面就總有一個金礦。
4.3. 告訴！當你在做事的時候，把它告訴所有人
如果你做了什么可重用的東西的話，讓其他人知道。別害羞，也不要為了保護自豪感而把你的工作成果藏起來。一旦養成共享工作成果的習慣，每個人都會獲得更多。
4.4. 小型代碼庫
對于代碼重用，一個常見的問題就是人們不從他們做過的代碼中做庫。一個可重用的類可能正隱蔽在一個程序目錄并且決不會有被分享的激動，因為程序員不會把類分拆出來加入庫中。
這樣的其中一個原因就是人們不喜歡做一個小庫，對小庫有一些不正確感覺。把這樣的感覺克服掉吧，電腦才不關心你有多少個庫呢。
如果你有一些代碼可以重用，而且不能放入一個已經存在的庫中，那么就做一個新的庫吧。如果人們真的考慮重用的話，庫不會在很長的一段時間里保持那么小的。
4.5. 知識庫
很多公司不清楚現有什么代碼可用，而且大多數程序員仍然沒有通過溝通他們已經做過了什么，或者一直在詢問現存什么代碼可用。解決這個的方法是有一個可用的知識庫。
理想的情況是，程序員可以到一個WEB頁，瀏覽或者查詢打包的知識庫列表，找到他們所要的。建立一個程序員可以自動維護的知識庫系統，是一個很不錯的做法。如果有一個專門的管理員來負責維護這個知識庫，那當然更好。
另一種方法是自動的從代碼中產生知識庫的做法。把通用的類、方法和標頭（subsystem headers）作為手冊或者是知識庫的一個條目。
5. 書寫注釋
5.1. 講一個故事
把你的注釋當作描述系統的一個故事。并且使得你的注釋能被機器解析后，以固定的格式放到手冊中去。類的注釋是故事的一部分，方法的名稱、方法的注釋、方法的實現也是故事一部分。所有的這些部分編織在一起，使得人們在以后的時間里能夠準確的知道你干了什么，為什么這么做。
5.2. 歸檔注釋
注釋的要歸檔才有意義，否則，假如在一個地方放一條注釋描述你做了什么選擇和你為什么這么做，只有考古學家才能發現這是最有用的信息。（如何歸檔另行規范）
5.3. 注釋結構
工程的每部分都有特定的注釋結構。 程序中的注釋，這里給出示例作為規范，注釋中以 * @ 為關鍵字的開始，以:為注釋關鍵字結尾。
5.3.1. 預定義關鍵字
關鍵字 含義
Purpose 表示類、屬性、方法要做些什么或者什么含義。
Package Name 類名
Author 作者
Modifications 修改記錄（編號規則為“No”＋日期＋“－”＋序號）
See 參考
Method Name 方法名
Parameter 參數名（包括類型）
Return 返回值（包括類型）
Attribute/Variable Name 屬性/變量名
Type 屬性/變量類型
5.3.2. 類的注釋
/**
* @ Purpose:
* 訪問數據庫的類，以ODBC作為通用訪問接口
* @Package Name: Database
* @Author: Forrest Gump gump@crtvu.edu.cn
* @Modifications:
* No20020523-100:
* odbc_fetch_into()參數位置第二和第三個位置調換
* John Johnson John@crtvu.edu.cn
* @See: (參照)
*/
class Database
{
……
}
5.3.3. 方法注釋
/**
* @Purpose:
* 執行一次查詢
* @Method Name: Query()
* @Parameter: string $queryStr SQL查詢字符串
* @Return: mixed 查詢返回值（結果集對象）
*/
function（$queryStr）{……}
5.3.4.屬性或變量注釋
/**
* @Purpose:
* 數據庫連接用戶名
* @Attribute/Variable Name: mDbUserName
* @Type: string
*/
var mDbUserName;
5.3.5. if (0)來注釋外部代碼塊
有時需要注釋大段的測試代碼，最簡單的方法就是使用if (0)塊：
function example()
{
great looking code
if (0) {
lots of code
}
more code
}
你不能使用/**/，因為注釋內部不能包含注釋，而大段的程序中可以包含注釋。
5.3.6. 目錄文檔
所有的目錄下都需要具有README文檔，其中包括：
該目錄的功能及其包含內容
一個對每一文件的在線說明（帶有link），每一個說明通常還應該提取文件標頭的一些屬性名字。
包括設置、使用說明
指導人們如何連接相關資源：
源文件索引
在線文檔
紙文檔
設計文檔
其他對讀者有幫助的東西
考慮一下，當每個原有的工程人員走了，在6個月之內來的一個新人，那個孤獨受驚嚇的探險者通過整個工程的源代碼目錄樹，閱讀說明文件，源文件的標頭說明等等做為地圖，他應該有能力穿越整個工程。
6. 其他
采用面向對象的設計方法；
理由
毫無疑問這是最接近人們自然思維的方法，可能前期會覺得沒有直接書寫來得快，能否試著保留自己的看法？好戲在后頭！
類的定義采用一個文件一個類，并且類名和文件名相同；
理由
越來越多的人接受了這種做法
事實證明這種方法使得項目的邏輯結構更清晰
類定義文件中，定義體之外不得出現諸如echo、print等輸出語句；
理由
出現這樣的語句，應該當做出現bug來看。
輸出網頁的頁面不出現SQL語句
理由
這是n層結構的編程思想所致，每層的任務不同，雖然可以越權行使，可能這樣很快捷，但我們不贊成這么干。
進行SQL執行的數據必須進行有效性檢測
特殊符號：
對于MS SQL Server，’%_[ ] 這些符號都是在書寫SQL語句中的特殊含義字符，在SQL執行前需要對這些字符進行處理。
腳本符號：
對于PHP腳本標記，如，在進入數據庫前需要檢測處理。
理由
這是數據庫編程的一個約定，很多參考書上也是這么說，這里需要強調一下。
在HTML網頁中盡量不要穿插PHP代碼
循環代碼和純粹變量輸出（類似于）除外。
理由
需要說明的是我們工作的上游，頁面設計者的工作，假如在頁面中穿插代碼，將破壞結構，這應當是我們需要避免的。
在這里的PHP代碼只負責顯示，多余的代碼顯然是不應該的。
沒有含義的數字
一個在源代碼中使用了的赤裸裸的數字是不可思議的數字，因為包括作者，在三個月內，沒人它的含義。例如：
if (22 == $foo) { start_thermo_nuclear_war(); }
else if (19 == $foo) { refund_lotso_money(); }
else if (16 == $foo) { infinite_loop(); }
else { cry_cause_im_lost(); }
在上例中22和19的含義是什么呢？如果一個數字改變了，或者這些數字只是簡單的錯誤，你會怎么想？
使用不可思議的數字是該程序員是業余運動員的重要標志，這樣的程序員從來沒有在團隊環境中工作過，又或者是為了維持代碼而不得不做的，否則他們永遠不會做這樣的事。
你應該用define()來給你想表示某樣東西的數值一個真正的名字，而不是采用赤裸裸的數字，例如：
define(" RESIDENT_WENT_CRAZY", "22");
define("WE_GOOFED", "19");
define("THEY_DIDNT_PAY", "16");
if (PRESIDENT_WENT_CRAZY == $foo) { start_thermo_nuclear_war(); }
else if (WE_GOOFED == $foo) { refund_lotso_money(); }
else if (THEY_DIDNT_PAY == $foo) { infinite_loop(); }
else { happy_days_i_know_why_im_here(); }
現在不是變得更好了么？
7. PHP文件擴展名
常見的PHP文件的擴展名有：html, .php, .php3, .php4, .phtml, .inc, .class...
這里我們約定：
所有瀏覽者可見頁面使用.html
所有類、函數庫文件使用.php
理由
擴展名描述的是那種數據是用戶將會收到的。PHP是解釋為HTML的。
8. PHP代碼標記
統一使用，只輸出變量時
本文由用戶 openkk 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！