php - 工作中的PHP编码标准: Insane,还是我？

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)只能调用函数，不能调用变量。通过使用“案例规则”，我们可以轻松地发现可疑的函数调用，例如:

$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

他们应该提出警告。您甚至可以创建一个命名规则来区分子例程和函数，以使发现这些错误更加容易。

明确禁止拥有兼具副作用和返回值的“功能正常”的怪物。

没有静态方法

工作场所的明显原因:可能有人在某个地方读到静电是邪恶的，然后盲目地跟随，而没有真正对其优点和缺点进行任何批评

更好的约定:

静态方法应该是无状态的(不能修改全局状态)。静态方法应该是一个函数，而不是子例程，因为测试无副作用函数比测试子例程的副作用要容易得多。静态方法应该很小(最多约4行)并且应该是自包含的(即不应过多调用其他太多静态方法)。大多数静态方法都应位于Utility类中。值得注意的异常(exception)是类(Class)工厂。允许使用此约定的异常(exception)情况，但应事先对其进行仔细检查。

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

工作场所的明显原因:对什么是面向对象的理解有缺陷。

争论:

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