說編程是一門藝術一點都不過分，無論從代碼中體現的思維還是給人的視覺感受都無可挑剔。當我們看別人的代碼時，第一眼感受到的就是作者的編碼風格，根據編碼風格大致可以感受到程序的好壞。良好的編碼風格看起來很有藝術的感覺，讀起來容易，易維護，出問題的幾率也小。而不良的編碼習慣導致代碼很難讀，思維不夠清晰，維護成本高，可能潛藏著更多的BUG。

藝術是用來欣賞的，但實際項目中需求的隨意不間斷無規則變動導致項目不可能成為藝術。雖然成不了藝術，但也不該讓人一眼就看到骯臟錯亂無規則的代碼，下面都是從實際項目中看到的一些問題，這些問題不是需要有多好的基礎、多好的技巧才能做到，只要留心注意下，每個人都可以做到，這里提出來一起探討。

1、頁面過長

上面的截圖為某個控制器的長度，還是刪除過不少的，2211行是個什么概念，如果一屏可以顯示40行代碼，也就是要翻50多屏才翻完。想要找到某個片段并不容易，也可以想象到其中要么是方法太長，要么是函數很多。如果是方法太長，說明耦合性很高，可以把一些片段寫成方法獨立出去，也方便其他地方調用；如果是方法太多，則說明可以將功能進一步按模塊細分，一個控制器文件做一個模塊的事情，如果模塊太大則細分為更小的模塊。

2、排版混亂

先看看上圖，看能不能發現什么問題？如果要給session加一個配置信息，很有可能寫在uri的上面，可仔細一看，session的數組結束于uri上面。不怪他人不小心，只怪這括號太有誘惑力。還有需要注意下tab鍵的個數，至少通過排版可以清楚的看到層級關系。還有一些代碼寫一行空兩行，空格時而三個時而五個，TAB錯綜復雜，注釋一片一片等等，這些直接影響到程序的閱讀。想要寫好程序，先從排版開始吧，找一些好的開源類庫看看錯落有致、整潔規范是個什么樣子。

3、注釋雜亂無章

排版注釋這些都是分不開的，注釋不好也直接影響到程序的閱讀，我們常習慣拷貝，很多時候直接連注釋也一并拷貝過來，可注釋在這里根本就不適用，那這些注釋就是沒用的、無效的；還有一些注釋就是一些廢話，太簡單的語句一看就懂的語句就不必加注釋了，注釋太多容易導致廢話太多，適可而止就好；還有一些注釋可能根本就是錯誤的，看到想罵人的那種。。。

上面的代碼一看就知道是飽經磨礪，很多調試的程序被注釋了，這是可以看到的。還有很多調試的注釋可能還在系統中運行，每天產生一些日志文件、日志信息等。其實類似的這些垃圾代碼是可以刪掉的，留在上面影響程序的閱讀，代碼看起來很亂，影響閱讀者的心情。

4、奇特的命名

寫程序時給變量、函數、常量等命名那是很平常的事，常用的就大小駝峰、下劃線分隔等，基本上采用英文單詞來表單名稱的含義，直接用拼音、拼音加英文的方式來命名應該是少數情況，感覺還是有點難理解，中間得停頓幾下才知道表達的什么意思。還有一些常量采用大寫字母這應該屬于國際標準吧，可還是看到直接使用小寫字母的情況，一下子都沒反應過來。如果要找的話，各種奇葩的名稱應該都可以找到。

命名是一種學問，個人可以慢慢去研究。簡單說下自己的命名方式，函數名采用小寫字母下劃線分隔方式；類屬性、類方法采用小駝峰；類名根據系統中大部分情況來，有下劃線分隔的，有大駝峰的，也有其他方式的；變量統一采用小寫字母下劃線分隔方式。單詞個數不要過多，超過3個就有點多了，超過5個那就太多了。類名可以用名詞，方法可以用動詞。

5、循環嵌套

嵌套的情況可能很多人存在，因為這種邏輯判斷是順利成章的事，IF什么條件，ELSE什么條件，滿足條件后還有條件就繼續嵌套，這樣子越嵌越深、越寫越復雜，想要找個某個塊并不容易，修改起來也很困難。 其實這個問題可以換種思維來寫，比如要判斷是否為AJAX提交：

if(! $this->input->is_ajax_request()) { //這里寫ELSE的內容 } //這里就表示該請求為AJAX請求

按照這種思維寫下去可以減少條件嵌套，嵌套的耦合性比較高，嵌套的越多出問題的可能性越大，也可以嘗試通過一些其他的方式來對嵌套解耦。

6、多環境問題，配置問題

配置的問題存在很多地方，數據庫配置直接寫在文件中，類的一些配置信息直接寫在屬性中，當要修改時是十分不方便的。以及多環境的配置，測試環境請求測試地址，生產環境配置生產環境配置，能靈活的做到不影響。關于多環境、初始化等在本博客CodeIgniter初始化中有提到過，思維對所有項目應該都適用。

7、生產環境上的測試方法、空方法、沒用的方法、大規模注釋的代碼

看看生產環境，運行久了之后少不了有些測試方法、大量注釋的代碼留在上面，是什么原因呢？上面的方法直接就可以看出是測試方法，也許有些時候并不是那么好分辨是否為測試方法，是否為有用的方法，后面的人接手后也糊里糊涂的，更加不敢動，特別是在一些比較重要的系統中，迷糊的情況下寧愿讓它繼續留在上面也不敢直接干掉它。 有些時候，事情比較急的時候我們可能會直接去注釋掉某個片段，寫個測試方法等，但事情處理完之后能不能把垃圾清理干凈？不要想著以后會再去處理，99%都不會了。

8、日志記錄問題

為了調試，最常用的手段還是打印，而生成環境不方便打印，所以變成了記日志。記日志有兩個需要考慮的地方，一是記錄在哪里？很多項目是直接記錄在根目錄，比較危險的，直接就可以訪問到了，所以不要把日志記錄在根目錄下。二是怎么記？常用的方法就直接file_put_contents，然后不斷的追加，最后一個日志文件加到幾G。。。產生的原因還是跟上面一樣，這些信息只增不減，慢慢的日志文件越來越多,直到產生問題。

9、不做任何判斷

在開的發時候常常從數據庫讀取出記錄后，不管是否取數據成功就直接用；獲取到的變量不管有沒有設置，有沒有值也就直接用，不做任何判斷性的邏輯，一個接口不成功也返回成功，一個操作提示操作成功實際卻失敗了。這個問題是很常見的，直接影響到程序的健壯性。做程序的不能這樣子，我們得告訴機器成功該怎么處理，取不到數據該怎么處理，這是程序員最基本的要求。

簡單的列舉了近段時間在項目中看到的一些問題，這里不針對具體的人，主要還是拋出問題，引起重視。也許被這樣的問題困擾過、吃過虧之后就記住了。

總之，不論自己還是他人的代碼，讀代碼的時間總是要比寫代碼的時間多得多。讀的過程很有可能碰到上面這些問題，于是心底一遍一遍的譴責作者，如果不想被譴責，就注意一下這些問題吧。

總結

以上是生活随笔為你收集整理的PHP被忽视的编码规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。