工作中的PHP编码标准:疯了,还是我？

Question

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

我需要知道以下两件事之一:(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.

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

如果你不能为他们辩护,你如何说服他们需要改变的坚定作者？

Answer 1

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

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类继承,基本数据类型在概念上也是一个对象.

Answer 2

如果你不能为他们辩护,你如何说服他们需要改变的坚定作者？

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

==

像其他人之前所说的那样是非常主观的,但这些都是我的意见/论点.

1. camelCase:函数,类名,方法和变量必须是camelCase.

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

2.函数/方法必须始终返回一个值(并且必须始终存储返回的值).

在我看来,这是无稽之谈.在几乎所有编程语言中,您都有某种"无效"类型.但是从测试的角度来看,如果你的功能没有副作用,那么它很有用.我不同意您的生产代码应始终使用返回值,尤其是在没有任何用途的情况下.

3.没有静态方法

我建议你阅读静态方法是从misko的可测性死亡

在实例化期间,我使用mocks/friendlies连接依赖项,这取代了真正的依赖项.使用程序编程没有任何"连线",因为没有对象,代码和数据是分开的.

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

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

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

Answer 3

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

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

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

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

1. Zend框架命名约定和Zend框架代码样式
2. 梨代码标准

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

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

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