Стандарты кодирования PHP на работе: Insane, или я?

Я предпочитаю, чтобы стандарты кодирования были логичными. Это мой аргумент в пользу того, почему следующий набор стандартов - нет.

Мне нужно знать одну из двух вещей: (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();

Какая причина заключается в том, чтобы не использовать статические методы или свойства? Не являются ли статические методы ответственными за логику, не связанную с экземпляром? Как инициализация или заполнение нового экземпляра?

Ваш код не является ООП, если все не возвращает объект

Там кусок кода, который выполняет запрос, проверяет его на несколько путей для ошибок, а затем обрабатывает результирующий массив. Он повторяется (копируется + вставлен) несколько раз, поэтому я помещаю его в базовый класс. Тогда мне сказали, что массив возвращает не ООП.

Как вы защищаете эти практики? Мне действительно нужно знать. Я чувствую, что беру сумасшедшие таблетки.

Если вы не можете защитить их,, как вы убедите непреклонного автора, их нужно изменить?

Ответ 1

Я бы предложил попытаться перечислить цели ваших стандартов кодирования и взвесить их в зависимости от того, какие цели являются самыми важными и какие цели менее важны.

PS: Я не говорю на PHP, поэтому некоторые из этих аргументов могут содержать откровенно неправильный PHP-код.

camelCase: функции, имена классов, методы и переменные должны быть camelCase.

Рабочее место Очевидный Причина: "согласованность" за счет "плотности информации по имени".

Аргумент:

1) Поскольку ключевому слову "new" всегда следует класс, тогда вы можете легко обнаружить незаконное создание экземпляра, например:

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

вызовет тревогу, потому что за "новым" должно следовать название TitleCase.

$value = new MyClass(); // correct

Полагаясь на Case, легко обнаружить эти ошибки.

3) Можно вызывать только функции, вы никогда не сможете вызывать переменные. Опираясь на правило Case, мы можем легко обнаружить вызовы с рывками, например:

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

3) Назначение имени функции и глобальным переменным является огромной сделкой, поскольку они часто приводят к поведению, которое трудно выполнить. Вот почему любое утверждение выглядит следующим образом:

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

следует тщательно изучить. Используя правило случая, легко определить эти потенциальные линии задачи.

В то время как точное правило случая может отличаться, рекомендуется иметь разные правила для каждого типа имен.

Функции/методы всегда должны возвращать значение (и возвращаемые значения должны всегда сохраняться).

На рабочем месте очевидная причина: очевидно, другое правило, порожденное слепой последовательностью. Преимущество состоит в том, что каждая строка кода, которая не является управлением потоком (например, looping, conditionals), является назначением.

Аргумент:

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; примечательными исключениями для этого являются классовые заводы. Исключения из этого соглашения разрешены, но должны быть тщательно изучены заранее.

Ваш код не является ООП, если все не возвращает объект

Рабочее место Очевидный Причина: неправильное понимание того, что такое ООП.

Аргумент:

Фундаментальные типы данных также концептуально являются объектами, даже если основной тип данных языка не наследует их класс Object.

Ответ 2

Если вы не можете защитить их, как вы убедить непреклонного автора, который им нужен изменить?

Давая сильные/правильные аргументы! Тем не менее, я думаю, вы должны изменить их только тогда, когда ваши аргументы действительно сильны! Поскольку большинство программистов на работе используются для этих стандартов кодирования, что является большой точкой для их использования.

Как и другие, до того, как это было довольно субъективно, но это мои мнения/аргументы.

1. camelCase: Функции, имена классов, методы и переменные должны быть camelCase.

Я бы использовал стиль PHP, если я код в PHP и стиль Camelcase, если я код на Java. Но не имеет значения, какой стиль вы выберете, пока вы остаетесь последовательным.

2. Функции/методы всегда должны возвращать значение (и возвращаемые значения должны всегда сохраняться).

Это, по-моему, бессмыслица. Почти во всех языках программирования у вас есть своего рода тип "void". Но с точки зрения тестирования большую часть времени это полезно, если ваша функция свободна от побочных эффектов. Я не согласен с тем, что ваш производственный код всегда должен использовать возвращаемое значение, особенно если оно не используется.

3. Нет статических методов

Я бы посоветовал вам читать статические методы - это смерть для проверки от misko

Во время создания я провожу зависимости с mocks/friendlies которые заменяют реальные зависимости. При процедурной программировании ничего не "проволока", поскольку нет объекты, код и данные отдельный.

Хотя PHP - динамический язык, поэтому это не большая проблема. Тем не менее, последний PHP поддерживает печать, так что я все еще думаю, что статические методы в большинстве случаев плохие.

4. Ваш код не является ООП, если все не возвращает объект

Я верю (не на 100% уверен), действительно, язык ООП должен сделать это (вернуть объект), но я не согласен с этим как на подобных языках, например, на Java (который, я считаю, не является trully oOP), Много раз ваши методы должны просто возвращать примитивы, такие как String/Int/Array/и т.д. Когда вы копируете и вставляете много кода, это должно быть признаком того, что с вашим дизайном что-то не совсем правильно. Вы должны реорганизовать его (но сначала у вас есть тесты (TDD), чтобы вы не нарушили какой-либо код).

Ответ 3

Многие из этих стандартов кодирования очень субъективны, но некоторые важные вещи для рассмотрения:

Получить единый набор правил именования и стиля кода и следовать им. Если вы еще не определили правила, убедитесь, что правила выработаны. Затем работайте над рефакторингом кода, чтобы следовать им. Это важный шаг для того, чтобы новые разработчики упростили переход на борт и сохранили кодирование среди разработчиков.
Требуется время и силы, чтобы изменить стандарты кодирования, установленные вашей компанией. Любое изменение правил означает, что код действительно должен пройти снова, чтобы обновить все, чтобы они соответствовали новым стандартам.

Помня об этом выше и смотря более подробно на конкретные стандарты кодирования PHP. Первое, на что нужно обратить внимание, это то, что ваша компания использует какие-либо структуры, посмотрите на стандарты кодирования для этой структуры, поскольку вы можете придерживаться этих правил, чтобы оставаться согласованными во всем коде. Я привел ссылки на пару популярных фреймворков PHP ниже:

Мои личные предпочтения в отношении ваших конкретных стилей кодирования:

1. camelCase: функции, имена классов, методы и переменные должны быть camelCase

Имена классов должны быть Pascal Case (Case Upper Camel).

Итак, в вашем примере:

class CustomerServiceBillingInstance
{
// Your class code here
}

Переменные и функции, которые я обычно чувствую, должны быть верблюжьим корпусом.

Итак, любой из них, в зависимости от ваших предпочтений в терминах подчеркивания:

$customerServiceBillingInstance = whatever;
$customer_service_billing_instance = whatever;

2. Функции/методы всегда должны возвращать значение (и возвращаемые значения должны всегда сохраняться).

Этот выглядит как дополнительный код, и, как вы могли бы использовать дополнительные ресурсы. Если функции не нужно ничего возвращать, ничего не возвращайте. Аналогично, если вам не важно, что возвращает функция, не храните ее. Нет смысла использовать дополнительную память для хранения того, что вы никогда не увидите.

Интересная вещь, которую вы, возможно, захотите попробовать, это запустить некоторые тесты. Посмотрите, требуется ли дополнительное время, чтобы вернуть что-то и сохранить его, даже если вы не смотрите на него.

3. Ваш код не является ООП, если все не возвращает объект

В этом случае, я чувствую, что вы должны провести линию где-то. Производительность мудрая, это быстрее для вас:

return false;

Чем заняться:

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

Защита стандарта кодирования

Чтобы защитить стандарт кодирования, который, по вашему мнению, является правильным (или показывая, почему другой не так хорош), вам действительно нужно будет поднять одну из двух точек.

Производительность. Если вы можете показать, что конкретный стандарт кодирования отрицательно влияет на производительность, вы можете рассмотреть возможность переключения.
Сопровождаемость/Удобочитаемость. Ваш код должен быть легко читаемым/понятным.

Цель состоит в том, чтобы найти счастливую медиану между производительностью и ремонтопригодностью/удобочитаемостью. Иногда это простое решение, потому что наиболее удобный вариант - это лучший результат, в то время как еще труднее сделать выбор.

Ответ 4

Стандарты и соглашения существуют по многим причинам, но большинство из этих причин сводятся к тому, что "они делают код более удобным для написания и поддержки". Вместо того, чтобы спрашивать: "Это правильный способ сделать X?" просто перейдем к преследованию и спросите, соблюден ли этот критерий. Последнее, в частности, просто вопрос определения. ООП - это средство, а не конец.

Ответ 5

Многие из них - дело вкуса. Вы можете спорить за или против camelCase весь день.

Однако сохранение возвращаемых значений, которые никогда не используются, неверно. Код не имеет значения. Код не выполняется. Вы также можете посыпать $foo = 47 * 3; вокруг кода.

Любой код, который не делает что-то полезное, должен быть удален.

Большая проблема заключается в том, что если вы работаете в команде, которая не работает, возможно, придет время для перемещения.

Ответ 6

Один из аспектов этого, который я не вижу никого, комментирующего, - это "2. Функции/методы всегда должны возвращать значение (и возвращаемые значения должны всегда сохраняться)".

Если вы не используете исключения, любая функция, которая может выйти из строя, должна вернуть значение. Последнее предложение неверно; возвращаемые значения не всегда должны быть ЗАПОМНЕНЫ, но их всегда нужно ПРОВЕРИТЬ. Опять же, это означает, что если вы не используете исключения, которые не распространены в наши дни, но это все равно стоит упомянуть.

Ответ 7

Насколько я знаю, многие из конвенций, опубликованных вами, также приветствуются платформой Zend PHP Framework. Вы не одиноки, я пользователь Codeigniter, и моя работа довольно велика при использовании Zend Framework. Эти соглашения об именах абсолютно смешны, и я честно могу видеть только преимущество использования camelCase для имен переменных, а не имен функций, поскольку это путает вещи.

Прочтите это: http://framework.zend.com/manual/en/coding-standard.naming-conventions.html

Соответствуют ли эти правила кодирования вам?