WordPress 编码标准 [指南]
我们拥有编码标准(不仅仅是 WordPress)的原因是为从事项目的程序员创造一个熟悉的环境。尤其是 WordPress,它涵盖了各种各样的产品。从核心本身到主题和插件,有很多东西要看——也有很多东西要混淆。
如果每个人都以相同的方式格式化他们的代码,使用注释、相同风格的文档等等,那么一起工作就会变得容易得多,加入一个新项目的学习曲线也不会那么陡峭。
代码库所处的状态放大了 WordPress 对凝聚力的需求。WordPress 不遵循严格的面向对象方法,也不使用 MVC 模式。无一例外地遵循 OOP 和 MVC 准则的项目(如Laravel)由于其结构而具有一致性和“内置”的最佳实践。
不幸的是,WordPress 很适合进行意大利式编码,也就是随心所欲。最佳实践之所以难以实施,仅仅是因为使用错误代码的产品可能同样有效(表面上)。
通过遵循WordPress 编码标准,您可以了解一些 WordPress 的编码精神,创建更多与 WordPress 兼容的产品。向社区展示您的关心,并努力编写高质量的代码。
有关 Hongkiat.com 的更多信息:
关于标准的一些说明
标准没有定义对与错。您可能不同意某条规则,例如,即使不需要,也应始终使用大括号。WordPress 编码标准的目的不是决定你是对还是错,而是决定它应该如何在 WordPress 中完成。
这些标准无须争论。使用标准不是反对您不喜欢的缩进样式的地方。如果编码标准中有某些内容,那么就那样做。WordPress 开发人员会因此而爱上您!也就是说,如果您不同意其中的某些内容,请提高您的声音并让人们知道。总是可以把事情做得更好,但你应该只在标准允许的情况下改变你的编码风格。
肛门滞留的一致性。如果您处于项目的最后 10%,并且刚刚发现您一直在使用不正确的类命名约定,请不要中途切换。以我个人的观点,我宁愿阅读始终不正确的内容,也不愿阅读时而正确时而错误的内容。您始终可以编写一个脚本来一次性更改内容,或者在最后通读您的代码。
遵循标准很难!将大括号与函数放在同一行而不是下面一行是非常容易的,即使您之前习惯于按 enter 键。然而,当你需要考虑 100 条小规则时,整个过程就变得有点容易出错了。尽管我在遵守标准方面态度强硬,但我和其他人一样对犯错感到内疚。归根结底,不正确的缩进并不是不可挽回的罪过。尽力遵守所有规则,您会及时了解所有内容。
WordPress 编码标准
现在 WordPress 有四个指南,每个指南针对使用的一种主要语言:PHP、HTML、Javascript 和 CSS。它们构成了更大的知识体系Core Contributor Handbook的一部分。通读所有内容需要一段时间,因此我突出显示了四种语言中的一些片段,我经常看到人们弄错了这些片段。
PHP
PHP 是 WordPress 的主要语言,是一种相当松散类型的语言,这使得它的监管时机成熟。
大括号样式
起始大括号应始终放在行尾。相关语句应与前一个右括号放在同一行。这最好用一个代码示例来证明:
1个
2个
3个
4个
5个
6个
7
|
if ( condition ) { // Do Something } elseif ( condition ) { // Do Something } else { // Do Something } |
宽敞的空间使用
我不喜欢压缩代码(我视力不好)所以这是我特别喜欢强制执行的代码。在逗号之后,逻辑运算符、比较运算符、字符串运算符和赋值运算符的两边, if、elseif、for、foreach和switch语句等之后放置空格。
说哪里不应该添加空格更容易!唯一不应该添加空格的情况是在类型转换或引用数组时。
一个相当令人困惑的例外是数组,其中数组键是一个变量,在这种情况下,使用空格。这个例子应该清楚地说明这一点:
1个
2个
3个
4个
5个
6个
7
8个
9
10
11
12
|
function my_function( $complete_array = null, $key_1 = 4, $key_2 = 'bar' ) { if ( null == $complete_array ) { $final_array = $complete_array ; } else { $key_1 = (integer) $key_1 ; $final_array [0] = 'this' ; $final_array [ $key_1 ] = 'is' ; $final_array [ $key_2 ] = 'an' ; $final_array [ 'last' ] = 'example' ; } return $final_array ; } |
命名约定
这个可能很难适应,尤其是当你来自不同的环境时。简而言之:
- 变量名全部小写,单词之间用下划线分隔
- 类名应该使用下划线分隔的大写单词。首字母缩略词应全部大写
- 常量应全部大写,并用下划线分隔
- 文件名应全部小写,以破折号分隔
尤达条件
以不同于您习惯的方式编写条件将防止解析错误。它看起来有点奇怪,但它是更好的代码。
1个
2个
3个
|
if ( 'Daniel' === $name ) { echo 'Write article you will' ; } |
HTML
HTML 并没有那么多与之相关的规则,我可以想出很多让事情更加模块化。在编写 HTML 时,您只需要知道五个规则:
- 您的代码必须针对W3C 验证程序进行验证。
- 自闭合 HTML 标签必须在正斜杠前正好有一个空格(这是我个人讨厌的一个,但它是 W3C 规范,而不仅仅是 WordPress 的烦恼)
- 属性和标签必须全部小写。唯一的例外是当属性值是供人类使用时,在这种情况下,它们应该自然地键入。
- 所有属性必须有值,必须用引号引起来(写的
<input disabled>
不对) - 缩进应使用制表符实现,并应遵循逻辑结构。
CSS
CSS 是另一种松散类型的语言,因此这里还有很多工作要做。即便如此,这些标准对编码人员来说还是很容易的。
选择器
选择器应根据需要进行限定,易于阅读,全部小写,单词用破折号分隔,属性选择器应使用双引号。这是一个简洁的例子:
1个
2个
3个
4个
5个
|
input[type= "text" ], input[type= "password" ], .name-field { background : #f1f1f1 ; } |
财产令
这些标准承认这里需要一些个人空间,因为它们没有规定 CSS 规则的特定顺序。他们所说的是您应该遵循有意义的语义结构。按关系对属性进行分组或按字母顺序对属性进行分组,只是不要随意写出来。
随机性的最大原因是“哦,我还需要添加边距”,然后继续将其添加到底部。花额外的 0.3 秒将规则添加到合乎逻辑的位置。
- 展示
- 定位
- 箱型
- 颜色和排版
- 其他
1个
2个
3个
4个
5个
6个
7
8个
|
.profile-modal { display : block ; position : absolute ; left : 100px ; top : 90px ; background : #ff9900 ; color : #fff ; } |
值格式化
这是我特别讨厌看到不一致的地方。如果您不遵循指南,那仍然比有时在值前看到一个空格要好;有时使用速记,有时不使用;有时使用 0 值的单位,有时不使用,等等。
值格式化非常复杂,但通过一些练习它确实很自然。查看Codex中有关格式化您的值的确切指南。
Javascript
以我的经验,Javascript 最容易出现问题。虽然许多开发人员知道相当多的 Javascript,但它是逐渐学习的,作为 HTML、CSS 和 PHP 的事后知识。当你刚开始使用一门新语言时,你会犯更多的错误,如果这些错误不会导致致命错误,它们就会在你心中根深蒂固。
在许多情况下,标准提到线路限制或声明“如果线路不太长”。这是指jQuery Style Guide,它对lines 施加了 100 个字符的限制。WordPress 指南基于 jQuery 指南,因此最好也阅读一下。
分号
这是一条最简单的规则,但却是一个经常被忽视的规则。永远不要仅仅因为你的代码没有分号就可以工作而省略分号。这只是马虎。
缩进
制表符应始终用于缩进。即使整个文件的内容都包含在一个闭包中,您也应该缩进闭包的内容。我不确定为什么,但在我阅读标准之前,未缩进的顶级闭包就让我很烦。
断线
断开长字符串时,始终在运算符后断开该行,不要让变量悬空。乍一看,这行断线很明显,您并没有忘记分号。
此外,如果条件很长,请将其分成多行并在其之前添加一个额外的制表符。这个在我看来很奇怪,但它在条件和身体之间增加的分离是非常明显的。
1个
2个
3个
4个
5个
|
if ( firstCondition() && secondCondition() && thirdCondition() ) { var html = 'This line consists of ' + n + 'words, so it should be broken down after ' + 'an operator' ; } |
jQuery 迭代
根据标准,jQuery 迭代(jQuery.each())
只能用于 jQuery 对象。您应该在 Javascript 中使用基本的for、for/in和while循环来迭代其他集合。
结论
有很多需要注意和跟踪的地方,没有人可以一次性应用所有这些。您应该使您的代码尽可能接近标准并努力严格遵循它们。
在我看来,一致性是最重要的规则。坚持不正确地做某事总比半途改变要好。对于格式化实践尤其如此,因为它们不会影响代码的功能,而且在大多数情况下,以后可以轻松地批量更改。
您是否讨厌编码标准中的某个元素,您认为应该添加一些东西吗?让我们在评论中知道!