Тема 14. Рекомендации по написанию эффективного кода на PHP

Даже если вы работаете над проектом в глубоком одиночестве, вероятность того, что вам больше никогда не придется возвращаться к нему позже, мала. А вот вероятность того, что вы не сможете быстро вспомнить "что там к чему" велика. Используя рекомендации, изложенные ниже, вы сможете сэкономить много времени не только себе, но и своим коллегам. Данный текст является переводом статьи "Php coding standart" Фредерика Кристьяна и несколько дополнен на основе статьи "с++ coding standart" Тода Хоффа и рекомендаций Zend для программирования Pear.

Кроме того – здесь рассматривается именно кодирование, т.е. как писать код на php, а не о том, что писать. Мы не будем обсуждать алгоритмы, но много внимания посвятим тому, как записать эти алгоритмы

Положительные и отрицательные стороны стандартизации

Когда проект пробуют привести к тем или иным стандартам, то происходит ряд хороших вещей:

· Программисты могут работать с любым кодом и легко понимать, о чём идет речь.

· Новый человек в проекте значительно быстрее может приступить к программированию.

· Новички в php экономят время на то, чтобы разработать свой личный новый стиль программирования и похоронить его в будущем.

· Новички в php не делают одни и те же ошибки раз за разом.

· Программисты объединяются в борьбе с единым врагом – автором стандарта.

Правда есть и плохие аспекты:

· Стандарты, как правило, разрабатываются теми, кто не умеет программировать.

· Стандарты, как правило, разрабатываются теми, кто не умеет программировать на php.

· Стандарты, как правило, разрабатываются прямо противоположно тому, как вы привыкли программировать.

· Стандарты ограничивают свободу.

· На стандарты все равно всем наплевать.

Опыт большинства проектов показывает, что использование стандартов приводит к тому, что проекты становятся более аккуратными и гибкими. Нужны ли стандарты для того, чтобы добиться успеха? Конечно нет. Но они помогаю в этом, а на пути к успеху глупо отказываться от помощи, которую предлагают.

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

В любом случае, только опытные и серьезные программисты могут играть по этим "правилам" и понимать, что стандарты просто необходимы, и в них заложено масса оснований самых различных программистов, и то, что вы до сих пор следовали только своему опыту – очень и очень плохо.

Отказ от использования стандартов выгоден только ленивой части команды, которые не заинтересованы в результате и хотят только чтобы их меньше трогали не совались в их работу.

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

· Это невозможно.

· Может быть это и возможно, но примитивно и неинтересно.

· Это правильно, и я бы сказал бы все точно также.

· Вообще-то это я первый придумал.

· Разве может быть иначе?

Правила определения имён

Названия (имена) – это сердце всего программирования, это результат глубокого осмысления процессов среды, в который будет существовать субъект. Только программист, который полностью понимается систему как единое целое, может придумать полностью отвечающее ситуации название. Если название соответствует, то все части соответствуют друг другу, связи ясны, понимание ситуации присутствует, и то, что люди ожидают от названия, будет соответствовать действительности.

Если вы обнаружите, что все ваши имена похожи на $temp, $d, $temp2, то, возможно, вам стоит серьезно пересмотреть взгляды.

Названия классов:

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

· Составляя названия более чем из 3 слов, вы рискуете чрезмерно усложнить проект.

· Старайтесь избегать искушения называть классы в виде производной названия родительского класса. Каждый класс несет в себе отдельную функцию и должен иметь собственное, самостоятельно название.

· Суффиксы зачастую полезны. Например, если Ваша система использует агентов, то название будет DownloadAgent соответствовать действительности.

· Используйте только английские названия. Старайтесь не использовать кириллистических названий и транскрипций.

· Используйте верхний регистра для разделения слов, и нижний для всех символов кроме первого.

· Первый символ в названии должен быть с большой буквы.

· Не используйте подчеркивание('_').

Пример

class NameOneTwo

Названия методов и функций:

· Обычно каждый метод и функция выполняют свое действие, таким образом, название должно четко объяснять, что делает этот класс или функция: CheckForErrors() вместо ErrorCheck(), DumpDataToFile() вместо DataFile(). Это также делает функции и объекты более distinguishable.

· Суфиксы часто полезны:

· Max – означает максимально возможное значение.

· Cnt – текущий счетчик изменяющего значения переменной.

· Key – ключ.

Например: RetryMax означает максимальное количество повторов, RetryCnt означает текущий счетчик повторов.

· Префиксы также часто полезны:

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

· Get – Получить значение.

· Set – Установить значение.

Для примера: IsMaxLimitReached.

· Не используйте все прописные (большие) буквы в аббревиатурах.

· Старайтесь не использовать написание "все прописные буквы" в названиях, даже когда речь идет об очень распространенной аббревиатуре. В любой ситуации.

· Используйте: GetHtmlStatistic.

· Не используйте: GetHTMLStatistic.

Мотивация: люди увидев название могут последовать самой не предсказуемой логике. Лучше использовать вариант, в котором двусмысленность невозможна.

Название атрибутов классов:

· Атрибуты (переменные) классов должны иметь префикс “m”.

· После “m” следует применять обычные правила для названий классов.

· “m” всегда стоит впереди всех дополнительных модификаторов.

· Использование 'm' позволяется избежать конфликтов с именами других элементов класса. Часто названия классов и атрибутов очень похожи, особенно не для автора.

Пример 14.2.1:

class NameOneTwo

{

function VarAbc() {};

function ErrorNumber() {};

var $mVarAbc;

var $mErrorNumber;

var $mrName;

}

Названия переменных:

· Используйте все буквы в нижнем регистре.

· Используйте подчеркивание '_' для разделения слов.

· Теперь все типы переменных отличаются друг от друга и их можно легко узнать в коде.

Пример 14.2.2:

function HandleError($errorNumber)

{

$error = new OsError;

$time_of_error = $error->GetTimeOfError();

$error_processor = $error->GetErrorProcessor();

}

· Все глобальные переменные следует префиксировать 'g'.

· Глобальные константы должны быть названы с использованием всех символов в верхнем регистре и с разделителем в виде подчеркивания “_” между словами. Уже стало традицией называть константы именно таким образом. Вы не спутаете тогда значение с другими глобальными значениями.

14.3. Правила оформления текста

Из всех методов, применяемых в программировании для оформления конструкций с фигурными скобками, только 2 из них вполне приемлемы.

· Размещение под ключевым словом и на одном уровне с ним:

if ($condition)

{

}

· Традиционная для UNIX практика размещения открывающей скобки на той же самой строке, где и ключевое слово и использование закрывающей скобки с тем же отступом, что и ключевое слово:

if ($condition) {

...

}

Отступы, пробелы и табуляция

· Используйте отступ в 3 или 4 пробела для каждого уровня.

· Не используйте табуляцию, используйте пробелы. Большинство редакторов может заменять табуляцию на пробелы.

· Делайте отступов настолько много, насколько нужно, но не слишком много. Тут нет жестких правил, насчет максимального уровня глубины отступов. Однако, если у вас более 4 или 5 уровней, то смысл подумать о том, чтобы написать алгоритм иначе.

Круглые скобки () с ключевыми словами и названиями функций:

· Не размещайте скобки сразу за ключевым словом. Отделяйте их пробелом.

· Размещайте скобки сразу после названия функции.

· Не используйте скобок в return функциях без наличия на то необходимости.

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

Пример 14.3.1:

if (condition)

{

}

while (condition)

{

}

strcmp($s, $s1);

return 1;

Не нашли, что искали? Воспользуйтесь поиском по сайту: