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

时间：2010-09-18 00:27:18

标签： php oop naming-conventions coding-style

我更喜欢编码标准是合乎逻辑的。这是我为什么以下一套标准没有的论点。

 我需要知道以下两件事之一：（1）为什么我错了，或者（2）如何说服我的团队改变它们。


camelCase：函数，类名，方法和变量必须是camelCase。

  • 难以区分变量和类
  • 违反PHP的小写/下划线变量/函数和UpperCamelCase类

示例：

$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。


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

如果你无法为他们辩护，你如何说服坚定的作者他们需要改变？

7 个答案:

答案 0 :(得分：12)

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

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

camelCase：函数，类名，方法和变量必须是camelCase。

工作场所的表观原因：“一致性”，代价是“名称中的信息密度”。

论据：

1）由于'new'关键字应始终后跟一个类，因此您可以轻松发现非法实例化，例如：

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

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

$value = new MyClass(); // correct

依靠Case可以轻松发现这些错误。

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

$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类中;值得注意的例外是Class Factories。允许例外，但应事先仔细审查。

除非所有内容都返回一个对象

，否则您的代码不是OOP

工作场所明显原因：对OOP是什么的理解有缺陷。

参数：

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

答案 1 :(得分：6)

  

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

通过提供强有力的论据！我认为你应该只在你的论点非常强大时改变它们！因为工作中的大多数程序员习惯于使用这些编码标准，这是使用它们的重点。

==

像之前所说的那样，这是非常主观的，但这些都是我的意见/论据。

<强> 1。 camelCase：函数，类名，方法和变量必须是camelCase。

如果我在PHP中编码，我会使用PHP样式，如果我在Java中编码，我将使用Camelcase样式。但只要你保持一致，你选择哪种风格并不重要。

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

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

第3。没有静态方法

我建议你阅读来自misko的static methods are death to testability

  

在实例化过程中我连接了   与mocks / friendlies的依赖关系   它取代了真正的依赖关系。   通过程序编程可以实现   没有什么可以“连线”，因为没有   对象，代码和数据   分开。

尽管PHP是一种动态语言，但它并不是一个很大的问题。最新的PHP确实支持打字，所以我仍然认为大多数时候静态方法都不好。

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

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

答案 2 :(得分：5)

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

  1. 获取一组代码命名和样式规则，并按照它们进行操作。如果您还没有定义规则，请确保找到规则。然后努力重构代码以遵循它们。这是一个重要的步骤，以便让新开发人员更容易加入，并使开发人员保持编码一致。

  2. 改变公司实施的编码标准需要时间和精力。对规则的任何更改都意味着代码必须再次通过以更新所有内容以符合新标准。

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

    1. Zend Framework Naming Conventions和Zend Framework Code Style
    2. Pear Code Standards

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

      <强> 1。 camelCase：函数，类名，方法和变量必须是camelCase

      班级名称应为Pascal Case（Upper Camel Case）。

      所以在你的例子中：

      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. <强>可维护性/可读性即可。您的代码应易于阅读/理解。

        3. 目标是找到性能与可维护性/可读性之间的愉快中间值。有时候这是一个简单的决定，因为最易于维护的选项也是表现最好的，有时则更难做出选择。

答案 3 :(得分：2)

标准和惯例存在的原因有很多，但大多数原因归结为“它们使代码更容易编写和维护”。而不是问“这是做X的正确方法吗？”只是切入追逐，并询问是否符合此标准。最后一点尤其仅仅是定义问题。 OOP是一种手段，而不是目的。

答案 4 :(得分：2)

其中许多都是品味问题。你可以整天争论或反对camelCase。

但是，存储从未使用过的返回值是错误的。代码没有任何价值。代码未执行。你也可以在代码周围撒上$foo = 47 * 3;。

必须删除任何无效的代码。

更大的问题是，如果你为一个无能的经理工作，可能是时候搬家了。

答案 5 :(得分：0)

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

如果您没有使用异常，那么 失败的任何函数都必须返回一个值。最后一句话是错误的;返回值并不总是需要存储，但它们总是需要检查。再说一次，如果您没有使用例外情况，这种情况现在并不常见，但仍然值得一提。

答案 6 :(得分：0)

据我所知，Zend PHP Framework也鼓励您发布的一些约定。你并不孤单，我是Codeigniter用户，我的工作在使用Zend Framework方面非常重要。这些命名约定是绝对荒谬的，老实说，我只能看到将camelCase用于变量名称的优势，而不是函数名称，因为它会使事情变得混乱。

阅读本文：http://framework.zend.com/manual/en/coding-standard.naming-conventions.html

这些编码约定对您来说是否熟悉？

相关问题
最新问题