特定於PHP-干凈的代碼，命名約定和文檔

Question

PHP的干凈代碼，命名約定和文檔的最佳實踐是什么？

我看到用戶/人說這是一種不好的做法，例如：

// Create an array to hold x values
$arr_x = array();

這是不必要的注釋，僅語法會解釋功能。 那應該更多地是描述腳本/功能功能的標題注釋，而不是程序的變量/流程。 例

/**
 * Create an array
 */
function create_array() {
   return array();
}

$arr_x = create_array();

// This is just to show the comments and the code is not tested or used except for this example

這使我無法正確使用語法，編碼和文檔（標題命名的原因）。

變量，函數和腳本命名約定可以接受什么，或者這是個人喜好？

$varX
function varX()
varX.php

要么

$var_x
function var_x()
var_x.php

我正在嘗試確定是否應該遵循一個標准。 謝謝

Answer 1

Zend Framework 在這里有一個PHP編碼標准文檔，其中應涵蓋諸如如何命名變量和函數之類的內容。

何時以及如何發表評論的方式與平台無關。 我認為一個好的一般規則是評論為什么要做某事，而不是如何做。 該代碼應該寫得明明足以使多么明顯。 （當然，有例外，例如使用可能需要解釋的特別復雜的算法。）

Answer 2

沒有標准，只有開發人員的意見。

我更喜歡用下划線定界的變量：

$my_var

但是對於功能我更喜歡駝峰式：

function myFunction() {}

至於注釋，是的，有時根本不需要// create array類的注釋，但是不要用一個內襯將它們拖延，它們不會在腳本執行時減慢速度。 我喜歡用一行簡潔地描述復雜腳本的每一步。

只要您和您的其他開發人員（項目中的其他人，第三部分公司等）可讀代碼，那么您就可以了。

Answer 3

最重要的是要保持一致。 除了描述性變量，函數和方法名之類的基礎知識之外，真正重要的是一致性。

如果您不想太認真考慮，可以隨意使用一種流行的編碼樣式指南，例如PEAR項目中的一種，或者JacobM剛剛發布的Zend Framework標准。

Answer 4

我使用codeigniter，這是他們的風格指南。
http://codeigniter.com/user_guide/general/styleguide.html

Answer 5

找到php_codesniffer支持的您喜歡的標准或與現有代碼庫最匹配的標准 -並安裝該工具-至少要有一個可用的工具來檢查您的代碼是否有差異。

Answer 6

重要的一件事是一致性。 無論您為開發團隊選擇什么（上面提到的任何標准），都要確保開發組織中的每個人都遵守它。 否則，代碼將很難閱讀，並且很難進行代碼審查。

Answer 7

Drupal是用PHP編寫的最大的開源代碼庫之一。

他們必須具有一些良好的代碼約定。

http://drupal.org/coding-standards

Answer 8

編碼標准已在php中更改。 如果您查看舊的框架，它們都使用Camel大小寫，在我看來，這可能會導致代碼錯誤。 對於像Java這樣的語言，但對php來說卻沒有道理。

較新的編碼標准和框架工作避免使用cammel case，並且優先使用lower_case下划線下划線分隔的變量名稱。 例如：fat_yak，而不是fatYak。

php的問題在於它將接受一個尚未聲明的新變量，並且由於Case很重要，因此可能有兩個名稱相同但大小寫不同的變量。 因此，重要的是始終將小寫字母與變量一起使用，以避免簡單的錯誤，否則可能不會被發現。 應該將相同的原則擴展到方法名稱，因為在編寫擴展類和覆蓋方法名稱時會遇到相同的問題。 （有可能放錯大寫字母並以第二個功能結尾，而不是按預期替換原始功能。）

我認為，有一些非常好的編碼標准會被camelCase方面所破壞。

此原則也應擴展到文件名。 由於unix服務器與Windows服務器在大小寫上有所不同，因此始終使用小寫字母可以避免很多問題。 並非如此，以大寫字母開頭的較不命名的階級可能是卑鄙的邪惡。

在類名中使用CamelCase很好。 如果您在這里輸入錯誤，它將立即被收取。 實際上，為了您自己的理智，在上課開始時必須使用大寫字母。 （我會以這樣的名字命名為Fat_yak，而不是FatYak，但我在那方面是少數，所以雖然可以使文件命名更容易..例如：Fat_yak.php而不是FatYak.php，但還是可以閉嘴。

使用4個空格代替制表符是一個非常有用的想法，尤其是在使用許多不同的編輯器的情況下。 （代碼在所有編輯器上看起來都一樣）

其他所有事情都是50-50的命題..每個標准似乎都選擇了兩個選項之一。.這是編碼標准令人失望的方面，因為還沒有一個明確的領導者出現。

eg: 
"true" or "TRUE"

eg:
function blah(){

}

or

function blah()
{

}

Answer 9

我將其稱為反模式。 當數據類型發生變化時，您將怎么辦？ 您會更改整個項目，還是可能更改使用代碼的許多其他項目？

我寧願使用簡單的方法：

$x
function x()
x.php

Answer 10

JacobM剛剛發布了一個很好的PHP標准文檔。 但是，如果我要編輯或添加現有代碼，則嘗試遵循前一位作者提出的樣式。