PHP語言的十二種特性

標籤：wordpress   瀏覽器   伺服器   java   最大的   

命名規範前後矛盾、版本相容相互衝突，PHP語言在各個層面上都給開發人員帶來了詭異而難解的謎局——這就是我們今天要討論的話題。我們真的對PHP深惡痛絕嗎?不，當然不是。如果真是這樣，我們就不會如此廣泛地使用Drupal、WordPress以及其它一些同類架構。假設我們真的討厭PHP，那麼最直接的辦法是轉向Java而非在這裡放什麼厥詞。不過需要提醒各位擁護者的是，也別因為熟悉而對PHP的那些缺陷視而不見。

轉換令人頭痛

　　在利用PHP進行項目建立的過程中，最大的挑戰之一在於牢記我們哪些時候需要輸入HTML、而哪些時代需要輸入PHP代碼。將二者相結合正是PHP語言的一大賣點，但要充分發揮其優勢卻著實不是易事。當我們查看某個檔案並關注其中的代碼時，首先需要搞清楚的就是——那些迫使我們不得不從HTML編寫轉向建立伺服器指令的標籤都在哪裡?各位必須要高度重視這些標籤，因為只有這樣我們才能將代碼與標記整合起來並使其順暢運作。當然，大多數情況下它只會讓人暈頭轉向。

　　標記的迷宮

　　將伺服器指令與瀏覽器標記結合起來實在是一種失誤。在Java這方面，其研發團隊嚴格遵循著MVC模式。資料模型被歸於一個檔案中，用於控制視圖的布局結構被歸於另外的檔案中，而用於構建控制器的邏輯也擁有自己的歸屬檔案。將這些條目區分並隔離開來能夠讓整個項目變得更有條理。但在PHP方面，最基本的設計思路就是開發人員應當將HTML標記與伺服器的控制器邏輯雜糅在一起。雖然我們不是沒辦法把它們區分開——大多數人也確實是這樣做的——不過一旦開始專門處理這項任務，很多朋友可能會像我們一樣問自己“為什麼我們非要用PHP不可?”

　　命名規範的不一致性與特殊性

　　大家知不知道我們什麼時候需要用到底線符號?可以看到，base64_encode方法中用到了底線，但urlencode則沒有。此外，php_uname這一名稱中使用了底線，而phpversion則沒有。為什麼會這樣?有沒有人考慮過這個問題?大家有沒有編輯過API?

　　與此同時，strcmp函數是不能夠大寫的，但strcasecmp卻可以。另外，strpos不能大寫，stripos則可以。到底是其中的字母“i”決定了能否大寫，還是函數整體名稱決定的?誰能記得住這麼多亂七八糟的規則?當然，開發人員們必須得記清楚。

　　災難般的排序

　　我們到底需要多少種排序函數?Java擁有一項基礎排序函數外加一個適用於所有對象的簡單介面。如果大家希望使用其它演算法、動手添加進去即可，而且大多數情況下標準函數已經完全夠用。而在PHP這邊，光是排序函數就能列出一條長長的清單：usort、sort、uksort以及array_sort等等(請注意，其中有一些還需要用到底線)。所以，請大家馬上把這些內容記到小本上，並祈禱自己在實際使用時不會搞混吧。

　　開源存在一定局限性

　　PHP也許確實擁有開源的諸多優勢，但緩衝等卓越功能卻只存在於商用版本當中。當然，這就是現實社會，畢竟Zend需要藉此賺取利潤。再有，該公司還需要通過向特定使用者群體出售最佳版本的方式支援整個PHP項目。抱怨這一點就像抱怨地心引力帶來的不便一樣，正確但卻毫無意義——地球就在那裡，根本不鳥你喜不喜歡。請大家活得理性一些，別總幻想著人們都能活在烏托邦式的開源環境當中。

　　糟糕的命名空間

　　大家有沒有建立自己函數的打算?如果有，請首先確定到底要使用PHP 5.3或者其後續版本，因為這裡正是命名空間出現的分界線。如果大家希望使用早期版本，則必須確保編碼內容與庫之間不存在衝突——畢竟在早期發展階段，PHP中的所有內容都具備全域化屬性。如果大家決定使用PHP 5.3並接受命名空間的加入，那麼請作好準備迎接“反斜線”——一個醜陋的標點符號——的降臨。

　　糟糕的type安全

　　這個問題簡直可怕，首先舉個PHP程式員們喜聞樂見的例子：

(string)"false" == (int)0

　　請注意，這並不屬於那種某些PHP支援者所爭論的“函數副作用”的典型情況。畢竟JavaScript當中也包含著大量由於type轉換所引發的同類情況。事實上，這一行想表達的是：左側為字串，右側為一個整數。只不過左側與右側內容完全相等。照這樣說來，如果讓PHP的設計者負責管理、世界上的每個人都能彼此和睦相處。

　　選擇太多，冗餘太多

　　PHP語言的一大特色就是可做的事太多，做事的途徑同樣太多。每一行命令的結尾都可以通過數字記號或者雙斜線來進行注釋。無論是浮點數字還是雙精確度數字都代表著同樣的含義。簡單的設計往往會被人們所忽略，因為大家在代碼貢獻過程中喜歡添加自己的小特性。這有點像依靠委員會體系進行設計，只不過該委員會從來沒考慮到過把其中的差異性剔除掉。

　　詭異的變數命名規則

　　把貨幣符號作為首碼實在不是個好主意。也許強制性地在所有變數前添加這個符號是為了更輕鬆地將其插入到模板當中，但這樣說來常數內容也同樣需要這麼個符號啊——為什麼實際上卻用不著呢?

　　CPU資源爭奪戰

　　對於32位計算裝置來說，整數數值過大始終是個無法迴避的難題。不過在另一方面，64位裝置卻不會受此影響，也就是說代碼在不同裝置上的運行狀態是不同的。大家可以在自己的筆記本上測試一下，我可以保證事實絕對是如此。但一旦把運行平台轉換成伺服器，情況則會再度變化。這時如果大家希望重現自己台式機上的錯誤，結果恐怕要令各位失望。惟一的好訊息是，32位裝置將很可能最終消失。

　　SQL注入

　　將SQL注入這一安全性漏洞的主要形式之一歸咎於PHP確實有失公允。人們在其它語言當中同樣會不慎輸入奇怪的SQL字串。之所以將其納入文章，主要是考慮到PHP語言更容易讓該漏洞攫取資料並發送至MySQL——簡單是輕而易舉。雖然新手在使用任何一種語言時都可能犯下同樣的錯誤，但這類情況在PHP中出現的機率明顯要高得多得多。

　　不相容式的變更太多太多

　　不同版本之間存在巨大差異，相容性問題也絕不是小事。以Java或者JavaScript為代表的程式設計語言在快速發展的同時也犧牲了向下相容的特性。事實上，老代碼在新裝置上無法啟動並執行問題並不少見。但這一切與PHP的情況其實不盡相同。在PHP方面，不同版本之間往往差別巨大，因此大家只能祈禱自己的伺服器已經安裝了正確的版本，否則只有在出現嚴重問題時才能意識到大事不妙。總而言之，在查看伺服器上是否有項目需要升級時，請優先把目光對準PHP。

PHP語言的十二種特性