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语句等之后放置空格。

说哪里不应该添加空格更容易！唯一不应该添加空格的情况是在类型转换或引用数组时。

一个相当令人困惑的例外是数组，其中数组键是一个变量，在这种情况下，使用空格。这个例子应该清楚地说明这一点：

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;
}

命名约定

这个可能很难适应，尤其是当你来自不同的环境时。简而言之：

变量名全部小写，单词之间用下划线分隔
类名应该使用下划线分隔的大写单词。首字母缩略词应全部大写
常量应全部大写，并用下划线分隔
文件名应全部小写，以破折号分隔

尤达条件

以不同于您习惯的方式编写条件将防止解析错误。它看起来有点奇怪，但它是更好的代码。

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循环来迭代其他集合。

结论

有很多需要注意和跟踪的地方，没有人可以一次性应用所有这些。您应该使您的代码尽可能接近标准并努力严格遵循它们。

在我看来，一致性是最重要的规则。坚持不正确地做某事总比半途改变要好。对于格式化实践尤其如此，因为它们不会影响代码的功能，而且在大多数情况下，以后可以轻松地批量更改。

您是否讨厌编码标准中的某个元素，您认为应该添加一些东西吗？让我们在评论中知道！