特定于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标准文档。 但是，如果我要编辑或添加现有代码，则尝试遵循前一位作者提出的样式。