作者：開源中國
來源：https://www.oschina.net/translate/
具有較強可讀性的代碼，能幫助你調試程序，不讓自己活得太累。
代碼可讀性是計算機編程領域中普遍存在的問題。這也是我們成為開發者首先要學習的事情之一。本文會詳細介紹在編寫強可讀性代碼時最佳實踐中最重要的一部分內容。
一
注釋和文檔
IDE（Integrated Development Environmnet，集成開發環境）在過去數年中已經存在了很長時間。使用 IDE 注釋代碼比以往容易得多。某些確切的注釋標準可以讓 IDE 和其它工具以不同的方式來完成注釋。
看個示例：
我在這裡添加到函數定義前的注釋可以在使用函數的時候顯示出來，甚至在其它文件中使用這個函數也沒問題。
下面是另一個示例，關於調用一個第三方庫的函數：
在這些示例中，注釋（或文檔）的類型是基於 PHPDoc 的，使用的 IDE 是 Aptana。
二
保持一致的縮進
假設你已經知道代碼需要縮進。不過值得注意的是，最好保持縮進樣式一致。
縮進代碼的方式很多，這裡最最常見的兩種：
風格 1:
風格 2:
我以前使用的風格 #2，但最近改為 #1 了。但這個問題只是一個偏好的問題。沒有「最好」的風格來讓每一個人都去遵循。實際上，最好的風格就是一致的風格。如果你是團隊的一員，或者你在向某個項目貢獻代碼，你就應該遵循項目中正在使用的風格。
縮進風格間並不總是會有明顯的區別。有時候，不同的規則會產生混淆。比如，在 PEAR 編碼標準中，前大括號「{」與控制結構在同一行，但在函數定義中卻需要換行。
PEAR 風格:
另外，請注意，縮進是用的 4 個空格而不是制表符。
這裡是 Wikipedia 中不同縮進風格的示例。
三
避免顯而易見的注釋
注釋代碼非常棒；但是，如果注釋只是簡單的重複就顯得多餘了。看看這個示例：
如果文本是顯而易見的，真的沒必要在注釋里再寫一次。
如果你一定要在代碼里寫點注釋，可以把它們合併在一行：
四
代碼分組
某些任務往往不是幾句代碼就能解決的，那最好把這些任務代碼分為不同的代碼段，在它們之間添加一些空行。
下面是一個簡單的示例：
在每段代碼前添加註釋可以加強視覺分離效果。
五
保持一致的命名規範
PHP 本身有時候並不遵循一致的命名規範：
- strpos() vs. str_split()
- imagetypes() vs. image_type_to_extension()
首先，名字應該有單詞的邊界。下面是兩種流行的選擇：
- 駝峰風格（camelCase）：除第一個單詞外每個單詞的第一個字母都大寫。
- 下劃線（underscores）: 在單詞間使用下劃線分隔，比如：mysql_real_escape_string()。
這一點與我前面提到使用不同縮進風格的情況相似。如果項目中已經在使用某個約定，你應該遵循它。另外，某些語言平台往往會有一個特定的命名規範。比如在 Java 中，多數代碼使用駝峰命名風格，而多數 PHP 程式設計師使用下劃線命名風格。
這些網絡也可以混合使得。有些開發者喜歡對過程函數和類使用下劃線風格，但對類方法使用駝峰風格：
再強調一下，沒有「最好」的風格，保持一致就好。
六
DRY 原則
DRY 代表不要重複你勞動（Don't Repeat Yourself）。也被稱為 DIE：複製是不可接受的（Duplication is Evil）。
該原則規定：
「每個知識必須在一個系統內具有一個唯一的、明確的、權威的表示。」
大多數應用程式（或通用的計算機）的目標是使重複的任務變得自動化。這個原則應該在所有的代碼中保留，包括 Web 應用程式中。同一段代碼不應該一再地被重複。
例如，大多數 Web 應用程式由許多頁面組成。這些頁面很可能包含通用的元素。標題和頁腳通常是最佳證明。將這些頁眉和頁腳在每個頁面中複製一份並不是一個好主意。Jeffrey Way 在此解釋了如何在 CodeIgniter 中創建模板。
七
避免深嵌套
過多的嵌套層次會使代碼變得難以閱讀和跟蹤
為了提高可讀性，通常會通過修改代碼來減少嵌套的層級：
八
限制行長度
人眼在閱讀窄長的列式文本時感覺更舒適，這也是為什麼報紙的文章都是這個樣子：
避免代碼行水平過長是一種良好的變成習慣
當然，如果有人，比如 Vim 用戶，想要在終端窗口中閱讀你的代碼，最好將代碼行的長度限制在 80 個字符左右。
九
文件和文件夾的組織
從技術上講，你可以在單個文件中編寫整個應用程式的代碼。但是，這對閱讀和維護來說將是一個噩夢。
在我的第一個編程項目中，我懂得了創建「包含文件」的作法。不過，我還沒有接觸過遠程組織。我創建了一個「inc」文件夾，其中包含兩個文件：db.php 和 functions.php。隨著應用的擴展，functions 文件也變得龐大和不可維護。
最好的方法之一就是使用框架或者模擬其文件夾結構。下面是 CodeIgniter 的代碼布局：
十
一致的臨時變量命名
通常，變量應該是描述性的，並且包含一個或多個單詞。但是，這並不一定適用於臨時變量。它們可以短到單個字符的長度。
對於具有相同作用的臨時變量，使用一致的命名是一個很好的做法。以下是我在代碼中常用的幾個示例：
探索 TDM 對於敏捷、DevOps 和持續交付中速度和質量的必要性。與 CA 技術一起攜手合作。