Проблема сопровождения кода в веб-приложениях часто игнорируется. Обычно это происходит по причине спешки. Быстро начать и завершить работу иногда представляется более важным, чем выполнять предварительное планирование. Однако небольшие затраты времени в начале могут сэкономить много времени в дальнейшем, когда потребуется создать следующую версию приложения.
Большинство крупных организаций, занимающихся информационными технологиями, устанавливают собственные стандарты кодирования — правила именования файлов и переменных, написания комментариев, применения выравнивания в коде и т.п.
Поскольку ранее разработка веб-приложений основывалась на понятии документа, стандартами кодирования в этой области нередко пренебрегали. Когда код пишется самостоятельно либо силами небольшой группы, значение стандартизации легко недооценить. Однако так не следует поступать, поскольку состав рабочей группы и масштаб проекта могут вырасти. В конечном итоге получится неразбериха, и программисты не смогут разобраться в существующем коде.
Цель выработки правил именования заключается в следующем:
Имена переменных должны описывать данные, которые они содержат. Если в переменной хранится фамилия, назовите ее $surname. Необходимо найти оптимальное соотношение между краткостью и читабельностью имен. Например, сохранение имени в переменной $n упростит набор кода, но усложнит его понимание. Имя $surname_of_the_current_user (фамилия текущего пользователя) более информативное, но неоправданно длинное (неудобно печатать и выше вероятность допустить опечатку при наборе).
Необходимо выработать правила использования регистров. Как уже упоминалось, в РНР имена переменных зависят от регистра. Потребуется решить, как будут записываться имена переменных: в нижнем регистре, верхнем регистре либо в их комбинации. Например, можно принять, что первые буквы слов будут прописными. Мы предпочитаем использовать только нижний регистр, поскольку это проще для запоминания.
Неплохо использовать регистр для различения переменных и констант. Обычно для переменных используют символы нижнего регистра (например, $result), а для констант — верхнего (например, PI).
Некоторые программисты присваивают двум переменным одно и то же имя, но с символами разного регистра, например, $name и $Name. Надеюсь, не стоит объяснять, почему подобная практика не рекомендуется.
Лучше избегать сложных схем применения регистров, например, $WaReZ. Они трудны для запоминания.
Кроме того, стоит выбрать конструкцию имен переменных, состоящих из несколько слов. Доводилось встречаться со всеми перечисленными ниже конструкциями:
$username
$user_name
$UserName
Совершенно не важно, какой из них будет отдано предпочтение, главное — применять ее последовательно. Имеет также смысл, придерживаться разумных ограничений в количестве слов — не более двух-трех.
Для имен функций применимы многие из рассмотренных соображений, но с парочкой отличий. Имена функций обычно основываются на глаголах. Например, следующие имена встроенных PHP-функций описывают действия, выполняемые над пере даваемыми параметрами: addslashes() (добавить обратные косые) и mysql_connect() (подключиться к MySQL). Это существенно упрощает восприятие кода. Обратите внимание, что в приведенных выше именах функций применены различные схемы именования переменных с использованием нескольких слов. В этом отношении РНР-функции непоследовательны. В какой-то мере это связано с тем, что они написаны большой группой программистов.
Кроме того, следует учитывать, что в РНР имена функций не зависят от регистра. Тем не менее, во избежание путаницы лучше придерживаться определенного формата.
Иногда применяют модульную схему именования, которая встречается во многих PHP-модулях — имя модуля служит префиксом имени функции. Например, имена всех функций модуля MySQL начинаются с префикса mysqli_, функций IMAP — с префикса imap_. Так, для функций модуля покупательской тележки (shopping cart) имеет смысл использовать префикс cart_.
В заключение отметим, что сами по себе правила именования не имеют большого значения. Важно лишь последовательно придерживаться выбранной схемы.
Все программы в разумных пределах должны комментироваться. Может возникнуть вопрос, каковы эти пределы. Обычно имеет смысл добавлять комментарии к каждому из следующих элементов:
Следующая общая рекомендация — писать комментарии в процессе работы над кодом. Не стоит рассчитывать на возможность вернуться к коду после завершения работы над проектом и внести в него комментарии. Уверен, что это никогда не удается, если только у вас не окажется намного менее напряженный график работы и гораздо больше самодисциплины, нежели у нас.
В любом языке программирования необходимо осмысленное и единообразное применение выравнивания (отступов) при оформлении кода. Это напоминает форматирование резюме или делового письма. Выравнивание существенно упрощает восприятие кода.
Обычно любой блок программы, принадлежащий управляющей структуре, выделяется отступом относительно окружающего кода. Отступ должен быть хорошо заметным (более одного пробела), но не слишком большим. Обычно мы против применения табуляции. Это ускоряет печать, но для многих мониторов отнимает слишком много экранного пространства. Во всех проектах мы используем отступы размером в два или три пробела.
Расположение фигурных скобок также заслуживает внимания. Ниже показаны два распространенных варианта:
Вариант 1:
if (condition) {
// какая-то обработка
}
Вариант 2:
if (condition)
{
// какая-то обработка
}
Какой из них использовать — дело вкуса. Опять-таки, во избежание неразберихи выбранный стиль должен последовательно применяться на протяжении всего проекта.
Монолитный код огромных размеров крайне неудобен. Некоторые программисты создают один большой сценарий, который все операции выполняет в одной главной строке кода. Намного лучше разбить код на функции и/или классы, а также поместить взаимосвязанные элементы в подключаемые классы. Например, имеет смысл включить все связанные с базами данных функции в файл с именем dbfunctions.php.
Ниже перечислены преимущества логического разбиения кода на блоки:
На начальном этапе работы над проектом необходимо уделить время разбиению проекта на компоненты, которые включаются в график работ. Придется рисовать схему функциональных модулей, но не следует излишне вдаваться в детали, поскольку схема может изменяться в процессе работы над проектом. Кроме того, необходимо решить, какие компоненты должны создаваться в первую очередь, какие зависят от других компонентов, и построить график разработки каждого из них.
Даже если все члены группы должны работать над всеми составляющими кода, обычно имеет смысл возложить персональную ответственность за каждый компонент на определенное лицо. В конечном счете этот человек будет отвечать за неполадки, связанные с данным компонентом. Кроме того, кто-то должен возложить на себя обязанности руководителя работ (build manager). Руководитель должен обеспечить продвижение работ над всеми компонентами первой очереди и работать над остальными. Обычно это же лицо осуществляет управление версиями, о чем речь пойдет ниже. Данный сотрудник может быть назначен руководителем проекта либо обладать особыми полномочиями.
Приступая к работе над проектом, необходимо продумать отражение структуры компонентов в структуре каталогов веб-сайта. Обычно содержать все компоненты в одном каталоге так же нецелесообразно, как и помещать все функции в один гигантский сценарий. Имеет смысл распределить каталоги между компонентами, логикой, содержимым и библиотеками общего кода. Структуру каталогов потребуется задокументировать и предоставить копию описания каждому разработчику проекта. Отсюда следующий момент.
Создавая библиотеки функций, необходимо делать их доступными для других программистов команды. Обычно каждый программист создает собственный набор баз данных или функций отладки. Это приводит к непроизводительным затратам времени. Следует предоставлять доступ к функциям и классам другим членам команды.
Помните, даже если код хранится в общедоступном каталоге, сотрудники не будут знать об этом, если только им не рассказать. Создайте систему документирования библиотек функций собственной разработки и сделайте ее доступной для остальных программистов.
Веб-инструмент
Обсудить на форуме