代码之家 › 专栏 › 技术社区 › Phill Pafford

特定于PHP的-干净的代码、命名约定和文档

coding-style syntax php

Phill Pafford · 技术社区 · 14 年前

对于干净的代码、命名约定和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

我正在努力寻找是否有一个我应该遵守的标准。谢谢

10 回复 | 直到 14 年前

Ben Everard 14 年前

没有标准,只有开发者的意见。

我喜欢用下划线分隔变量:

$my_var

但对于功能,我更喜欢驼色的:

function myFunction() {}

至于评论,是的,有时评论如 // create array 一点也不需要,但是不要使用一行程序来拖延,它们不会在执行脚本时减慢速度。我喜欢用一行字来清晰地描述复杂脚本的每一步。

只要您和您的开发人员(项目中的其他人、第三方公司等)能够阅读您的代码,那么您就可以了。

Jacob Mattison 14 年前

Zend框架有一个PHP编码标准文档 here 这应该包括如何命名变量和函数等内容。

评论的时间和方式远不是平台特定的。我认为一个好的一般规则是评论 为什么? 做了点什么,而不是怎样 . 代码应该写得足够清楚怎样显而易见。(当然,也有例外,例如使用可能需要解释的特别复杂的算法。)

timdev 14 年前

最重要的是保持一致。除了像描述性变量、函数和方法名这样的基本概念之外,真正重要的是一致性。

如果您不想太费劲地考虑它,可以随意使用一个流行的编码风格指南,比如Pear项目中的指南,或者Jacobm刚刚发布的Zend框架标准。

Eric 14 年前

我用代码点火器,这是他们的风格指南。
http://codeigniter.com/user_guide/general/styleguide.html

kguest wshcdr 14 年前

找到一个您喜欢的标准,或与现有代码库最接近的、由支持的标准 php_codesniffer -然后安装这个工具-至少你有一个工具可以使用它来检查你的代码是否存在差异。

Alex Weinstein 14 年前

一件重要的事情是一致性。无论您为您的开发团队选择什么——上面提到的任何标准——都要确保您的开发组织中的每个人都遵守它。否则,代码将很难阅读,并且事情将很难代码审查。

Yada 14 年前

Drupal是用PHP编写的最大的开源代码库之一。

他们必须有一些良好的代码约定。

http://drupal.org/coding-standards

Bingy 14 年前

PHP中的编码标准一直在变化。如果您看看旧框架,它们都使用camel case,在我看来,这可能会导致代码中的错误。它对于Java这样的语言来说是有意义的,但不是PHP。

最新的编码标准和框架避免使用cammel大小写,并且优先使用小写下划线分隔变量名。肥肉牦牛,而不是肥肉牦牛。

PHP的问题在于它将接受一个未声明的新变量,由于case很重要,所以有可能有两个同名但大小写不同的变量。因此,INMHO必须始终使用小写字母和变量,以避免简单的错误,否则可能无法检测到。同样的原则应该扩展到方法名,因为在编写扩展类和重写方法名时会遇到同样的问题。(可能会将大写字母放错并以第二个函数结尾,而不是按预期替换原始函数。)

我认为有一些非常好的编码标准被这个camelcase方面破坏了。

这个原则也应该扩展到文件名。考虑到Unix服务器在情况上与Windows服务器不同,imho许多问题都可以通过始终使用小写来避免。用大写字母开头的非更少命名类可能是一种nessescary邪恶。

在类名中使用camelcase是可以的。如果你在这里犯了一个错误,它会马上被取走。事实上,在课堂开始时使用大写字母对你的心智是强制性的。(我想叫他们像这个肥肉牦牛,而不是肥肉牦牛,但我在那一个上是少数,所以可以闭嘴..虽然这会使命名文件更容易……例如:fat_yak.php而不是fat yak.php)

使用4个空格代替制表符是一个非常有用的想法,特别是在使用许多不同的编辑器时。(代码在所有编辑器上看起来都一样)

其他一切都是50比50的提议。每个标准似乎都选择了两个选项中的一个。这是编码标准令人失望的方面,因为还没有出现明确的领导者。

eg: 
"true" or "TRUE"

eg:
function blah(){

}

or

function blah()
{

}

Szymon LipiÅski 14 年前

我称之为反模式。当数据类型发生更改时,您将做什么?您是否只需更改整个项目,或者其他许多使用您的代码的项目?

我宁愿使用简单的:

$x
function x()
x.php

Banjer 14 年前

Jacobm刚刚发布了一个好的PHP标准文档。但是,如果我正在编辑或添加现有代码,我会尝试遵循前一位作者所设计的样式。