工作中的 PHP 编码标准：疯了，还是我疯了？

Question

我更喜欢合乎逻辑的编码标准。这就是我对为什么以下一组标准不是这样的论点。

我需要知道以下两件事之一：(1) 为什么我错了，或者 (2) 如何说服我的团队进行更改。

camelCase：函数、类名、方法和变量必须采用驼峰命名法。

• 难以区分变量和类 与
• PHP 的小写/下划线变量/函数和大驼峰命名法的类背道而驰

示例：

$customerServiceBillingInstance = new customerServiceBillingInstance(); // theirs
$customer_service_billing_instance = new CustomerServiceBillingInstance();

函数/方法必须始终返回一个值（并且返回值必须始终被存储）。

这出现在我们的数百个 php 页面上：

$equipmentList = new equipmentList();
$success = $equipmentList->loadFromDatabase(true, '');
$success = $equipmentList->setCustomerList();
$success = $equipmentList->setServerList();
$success = $equipmentList->setObjectList();
$success = $equipmentList->setOwnerList();
$success = $equipmentList->setAccessList();

返回值很少使用，但总是被存储。它鼓励使用复制和粘贴。

没有静态方法

像下面这样的行在代码库中出现了数千次：

$equipmentList = new equipmentList();
$success = $equipmentList->loadFromDatabase();

我更喜欢：

$equipmentList = equipmentList::load();

有什么理由不使用静态方法或属性？静态方法不负责非特定于实例的逻辑吗？喜欢初始化或填充新实例吗？

除非所有内容都返回一个对象，否则您的代码不是 OOP

有一段代码执行查询，以多种方式检查错误，然后处理结果数组。它被重复（复制+粘贴）多次，所以我把它放在基类中。然后我被告知返回数组不是 OOP。

你如何捍卫这些做法？我真的需要知道。我感觉我正在服用疯狂的药片。

如果你不能为他们辩护，你如何说服顽固的作者他们需要改变？

Answer 1

我建议尝试列出编码标准的目标，并根据哪些目标最重要、哪些目标不太重要来权衡它们。

PS：我不会说 PHP，因此其中一些参数可能包含明显不正确的 PHP 代码。

驼峰命名法：函数、类名、方法和变量必须采用驼峰命名法。

工作场所的明显原因：以“名义上的信息密度”为代价的“一致性”。

论点：

1）由于“new”关键字后面应该始终跟一个类，那么您可以轻松发现非法实例化，例如：

$value = new functionName();
$value = new local_variable();
$value = new GLOBAL_VARIABLE();

会发出警报，因为“new”后面应该跟一个 TitleCase 名称。

$value = new MyClass(); // correct

依靠 Case 可以很容易地发现这些错误。

3）只能调用函数，不能调用变量。通过依赖 Case 规则，我们可以很容易地发现可疑的函数调用，例如：

$value = $inst->ClassName();
$value = $inst->instance_variable();
$value = $GLOBAL_VARIABLE(); 

3）分配给函数名称和全局变量是一件大事，因为它们通常会导致难以遵循的行为。这就是为什么任何看起来像这样的声明：

$GLOBAL = $value;
$someFunction = $anotherFunction;

都应该受到严格审查。使用案例规则，很容易发现这些潜在的问题线。

虽然确切的大小写规则可能有所不同，但最好对每种不同类型的名称采用不同的大小写规则。

函数/方法必须始终返回一个值（并且返回的值必须始终被存储）。

工作场所的明显原因：显然是出于盲目一致性而诞生的另一条规则。优点是每行不是流程控制的代码（例如循环、条件）都是赋值。

论据：

1）强制分配会产生不必要的长行，这会损害可读性，因为它增加了屏幕上不相关信息的数量。

2）代码稍微慢一些，因为每个函数调用都会涉及两个不必要的操作：值返回和赋值。

更好的约定：

学习函数式编程范例。区分“子程序”和“函数”。子例程通过副作用完成其所有工作，并且不返回值，因此它的返回值永远不需要存储在任何地方（子例程不应返回错误代码；如果确实是这样，则使用异常）必要的）。函数不得有任何副作用，因此必须立即使用其返回值（用于进一步计算或存储在某处）。通过无副作用函数策略，调用函数并忽略其返回值会浪费处理器周期；因此该线可以被移除。

因此，存在三种类型的正确调用：

mySubroutine(arg);            // subroutine, no need to check return value
$v = myFunction(arg);         // return value is stored
if (myFunction(arg)) { ... }  // return value used immediately

例如，您永远不应该这样做：

$v = mySubroutine(arg);  // subroutine should never have a return value!
myFunction(arg);         // there is no point calling side-effect free function and ignoring its return value

并且它们应该发出警告。您甚至可以创建命名规则来区分子例程和函数，从而更容易发现这些错误。

特别禁止拥有同时具有副作用和返回值的“functiroutine”怪物。

没有静态方法

工作场所 明显原因：可能有人在某处读到静态是邪恶的，并且盲目跟随而没有真正对其优缺点进行任何批判性评估

更好的约定：

静态方法应该是无状态的（不修改全局状态）。静态方法应该是函数，而不是子例程，因为测试无副作用函数比测试子例程的副作用更容易。静态方法应该很小（最多~4行）并且应该是独立的（即不应该太深入地调用太多其他静态方法）。大多数静态方法应该存在于Utility类中；值得注意的例外是类工厂。该约定的例外情况是允许的，但应事先进行严格审查。

除非所有内容都返回一个对象，否则您的代码不是 OOP。

Workplace 明显原因：对 OOP 的理解存在缺陷。

论证：

基本数据类型在概念上也是一个对象，即使语言的基本数据类型不是从其 Object 类继承的。

Answer 2

如果你不能保护他们，你怎么办？
说服他们需要的坚定作者
要改变吗？

通过给出强有力/有效的论据！不过我认为只有当你的论点非常有力时你才应该改变它们！因为大多数工作中的程序员都习惯了这些编码标准，这是使用它们的一个重要原因。

==

就像其他人之前所说的那样，这是相当主观的，但这些是我的意见/论点。

1.驼峰命名法：函数、类名、方法和变量必须采用驼峰命名法。

如果我用 PHP 编写代码，我会使用 PHP 风格；如果我用 Java 编码，我会使用 Camelcase 风格。但只要保持一致，选择哪种风格并不重要。

2.函数/方法必须始终返回一个值（并且返回的值必须始终被存储）。

在我看来这是无稽之谈。在几乎所有编程语言中，都有某种“void”类型。但从测试的角度来看，大多数时候，如果您的函数没有副作用，那么它是有用的。我不同意您的生产代码应该始终使用返回值，特别是如果它没有任何用处。

3.没有静态方法

我建议您阅读静态方法是可测试性的死亡来自misko

在实例化期间，我连接了
与模拟/友谊的依赖关系
它取代了真正的依赖项。
通过过程化编程，有
没有什么可以“接线”的，因为没有
对象，代码和数据是
分开。

尽管 PHP 是一种动态语言，所以这并不是一个大问题。最新的 PHP 仍然支持输入，所以我仍然认为大多数时候静态方法是不好的。

4.你的代码不是 OOP，除非一切都返回一个对象

我相信（不是 100% 确定）真正的 OOP 语言应该这样做（返回一个对象），但我不同意这一点，就像类似的语言一样例如 Java（我认为它不是真正的 OOP）。很多时候你的方法应该只返回像 String/Int/Array/etc 这样的基元。当您复制和粘贴大量代码时，这应该表明您的设计并不完全正确。您应该重构它（但首先准备好测试（TDD），这样就不会破坏任何代码）。

Answer 3

其中许多编码标准非常主观，但需要考虑的一些重要事项是：

1. 获取一组代码命名和样式规则，并遵循它们。如果您还没有定义规则，请确保弄清楚规则。然后重构代码以遵循它们。这是一个重要的步骤，可以让新开发人员更轻松地加入，并保持开发人员之间的编码一致。

2. 改变公司制定的编码标准需要时间和精力。对规则的任何更改都意味着确实必须再次检查代码以更新所有内容以与新标准保持一致。

牢记上述内容，并更多地关注特定的 PHP 编码标准。首先要考虑的是，如果您的公司使用任何类型的框架，请查看该框架的编码标准，因为您可能希望坚持使用这些标准，以便在所有代码中保持一致。我在下面列出了几个流行的 PHP 框架的链接：

1. Zend Framework 命名约定 和 Zend Framework 代码样式< /a>
2. Pear 代码标准

我个人对特定编码风格的偏好：

<强>1。驼峰命名法：函数、类名、方法和变量必须采用驼峰命名法

类名应采用帕斯卡命名法（大驼峰命名法）。

所以在你的例子中：

class CustomerServiceBillingInstance
{
// Your class code here
}

变量和函数我通常认为应该是驼峰式大小写。

因此，无论是其中之一，具体取决于您对下划线的偏好：

$customerServiceBillingInstance = whatever;
$customer_service_billing_instance = whatever;

2。函数/方法必须始终返回一个值（并且返回的值必须始终被存储）。

这看起来像是额外的代码，并且您最终可能会使用额外的资源。如果函数不需要返回任何内容，则不要返回任何内容。同样，如果您不关心函数返回什么，则不要存储它。使用额外的内存来存储您永远不会查看的内容是没有意义的。

您可能想尝试的一件有趣的事情是运行一些基准测试。看看是否需要额外的时间来归还某些东西并将其存储起来，即使您没有查看它。

3.除非所有内容都返回一个对象，否则你的代码不是 OOP

在这种情况下，我觉得你必须在某个地方划清界限。就性能而言，执行以下操作比执行

return false;

以下操作更快：

return new Boolean(false); // This would use up unnecessary resources but not add very much to readability or maintainability in my opinion.

---

捍卫编码标准

为了捍卫您认为正确的编码标准（或说明为什么另一个标准不那么好），您确实是必须提出两点之一。

1. 性能。如果您可以证明特定的编码标准对性能产生不利影响，您可能需要考虑切换。

2. 可维护性/可读性。您的代码应该易于阅读/理解。

目标是找到性能和可维护性/可读性之间的最佳中值。有时这是一个简单的决定，因为最可维护的选项也是性能最好的，而有时则需要做出更困难的选择。

Answer 4

标准和约定的存在有很多原因，但大多数原因都归结为“它们使代码更易于编写和维护”。而不是问“这是做 X 的正确方法吗？”直接切入正题，询问是否满足这个标准。最后一点只是一个定义问题。 OOP是一种手段，而不是目的。

Answer 5

其中许多都是品味问题。你可以整天争论支持或反对驼峰命名法。

然而，存储从未使用过的返回值是错误的。代码没有任何价值。代码没有被执行。您也可以在代码周围添加 $foo = 47 * 3; 。

任何没有做有用事情的代码都必须被删除。

更大的问题是，如果你为一位无能的经理工作，那么可能是时候跳槽了。

Answer 6

我没有看到其他人评论的一方面是“2.函数/方法必须始终返回一个值（并且返回的值必须始终被存储）”。

如果您不使用异常，则任何可能失败的函数都必须返回一个值。最后一句措辞错误；返回值并不总是需要存储，但总是需要检查。再说一遍，如果您不使用异常，这在当今并不常见，但仍然值得一提。

Answer 7

据我所知，您发布的许多约定也受到 Zend PHP 框架的鼓励。您并不孤单，我是 Codeigniter 用户，我的工作主要是使用 Zend Framework。这些命名约定绝对是荒谬的，老实说，我只能看到使用驼峰命名法作为变量名称的优点，而不是函数名称，因为它使事情变得混乱。

阅读此内容： http://framework.zend.com/manual/ en/coding-standard.naming-conventions.html

这些编码约定您看起来熟悉吗？