Я бы предложил попытаться перечислить цели ваших стандартов кодирования и взвесить их в зависимости от того, какие цели являются наиболее важными, а какие - менее важными.
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;
должно быть тщательно изучено. Используя Case Rule, легко обнаружить эти потенциальные проблемы.
Несмотря на то, что точное Case Case Rule может варьироваться, было бы неплохо иметь разные Case Case Rule для каждого типа имен.
Функции / методы должны всегда возвращать значение (и возвращаемые значения всегда должны храниться).
Очевидная причина рабочего места: очевидно, еще одно правило, рожденное из слепой последовательности. Преимущество состоит в том, что каждая строка кода, которая не является управлением потоком (например, зацикливание, условные выражения), является присваиванием.
Аргумент:
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; Заметные исключения к этому - Класс Фабрики. Исключения из этого соглашения допускаются, но их следует тщательно изучить заранее.
Ваш код не является ООП, если все не возвращает объект
На рабочем месте Очевидная причина: ошибочное понимание того, что такое ООП.
Аргумент:
Фундаментальные типы данных концептуально также являются объектами, даже если базовые типы данных языка не наследуются от их класса Object.