Лучшие приложения написаны правильно. Это звучит как очевидное утверждение, но под «правильно» я подразумеваю, что код не только хорошо выполняет свою работу, но также легко добавляется, поддерживается и отлаживается.
Этот «поддерживаемый код» является популярным предметом обсуждения среди тех, кто связан с PHP и, возможно, с другими языками. Нет ничего хуже, чем наследовать приложение или вносить изменения в код, для расшифровки которого требуется много энергии — в конечном итоге вы перебираете строки и строки кода, которые не проясняют его назначение или намерения. Просматривать незнакомый код гораздо проще, если он хорошо продуман и все аккуратно прокомментировано с деталями, объясняющими любые сложные конструкции и причины их возникновения.
В этой статье я объясню, почему стандарты кодирования важны не только для отдельного разработчика или команды разработчиков, но и для пользователей сценариев.
Проблема
Когда мы изучаем новый язык, мы обычно начинаем кодировать в определенном стиле. В большинстве случаев мы будем писать в стиле, который нам нужен, а не в том, что нам предложили. Но как только мы начнем кодировать, используя определенный стиль, такой как разговорный диалект, это станет второй натурой — мы будем использовать этот стиль во всем, что мы создаем. Такой стиль может включать соглашения, которые мы используем для именования переменных и функций (например, $userName , $username или $user_name ) и как мы комментируем нашу работу. Любой стиль должен гарантировать, что мы можем легко читать наш код.
Однако, что происходит, когда мы начинаем кодировать большие проекты и вводить дополнительных людей, чтобы помочь создать большое приложение? Конфликты в том, как вы пишете свой код, будут определенно появляться.
Решение: документ по стандартам кодирования
Документ о стандартах кодирования говорит разработчикам, как они должны писать свой код. Вместо того, чтобы каждый разработчик писал свой собственный предпочтительный стиль, он будет писать весь код в соответствии со стандартами, изложенными в документе. Это гарантирует, что большой проект закодирован в едином стиле — части не пишутся по-разному разными программистами. Это решение не только облегчает понимание кода, но и гарантирует, что любой разработчик, который просматривает код, будет знать, чего ожидать от всего приложения.
Стандарты кодирования великолепны — но как вы решаете, какие стандарты вы хотите применять, и как они будут определены? Когда вы формулируете свой идеальный стиль кодирования, вы должны подумать об этих моментах:
- Вы действительно можете прочитать код? Это четко разнесено?
- Вы разделяете блоки кода на «абзацы», чтобы различные разделы были легко определены?
- Используете ли вы отступ, чтобы показать, где управляющие структуры (если, иначе, while и другие циклы) начинаются и заканчиваются, и где находится код внутри них?
- Согласны ли ваши соглашения по именованию переменных в коде и кратко ли они описывают те данные, которые они будут содержать?
- Названы ли функции в соответствии с тем, что они делают?
Рассмотрев эти моменты, вы можете приступить к разработке стандартов кодирования. Проконсультируйтесь с членами вашей команды (если таковые имеются) и сравните, как они кодируют ваш собственный стиль — вам не следует навязывать полное изменение всем. Компромисс и включить элементы стиля каждого. Если кто-то долго программировал определенным образом, то разработчику потребуется некоторое время, чтобы перейти на новый метод. Разработчики, скорее всего, постепенно примут стиль, так как акцент развивается со временем.
Создать обслуживаемый код
Как мы уже говорили в начале этого обсуждения, вы хотите создать поддерживаемый код. Если вы прекратите разработку проекта, вернетесь к нему через несколько месяцев или передадите разработку кому-то другому, вы (и другие разработчики) захотите понять, что происходит в коде. Мы продолжаем упоминать «читабельность», но что на самом деле составляет «читаемый код»? Ответ на этот вопрос, очевидно, будет отличаться для каждого программиста, но я считаю, что есть некоторые общие основы, которые мы обсудим сейчас. Я использовал PHP для обозначения различных стилей здесь, но похожие идеи будут применяться и к другим языкам:
// Method 1 if (condition) function1($a, $b, $c); for ($i < 7 && $j > 8 || $k == 4) a($i); // Method 2 if (condition) { get_user($id, $username, $key); } for (($i < 7) && (($j < 8) || ($k == 4))) { display_graph($value); }
Вот два способа написания одного и того же кода: вы можете увидеть разницу между легко читаемым и сложным, но более быстро написанным кодом. Даже если вы не очень много знаете PHP, вы, вероятно, заметили, что второй фрагмент кода намного проще и понятнее. Я назвал функции, используя глагол ( get , display ), использовал имена переменных, которые описывают содержащиеся в них данные, и использовал скобки, чтобы показать, что является условием for . Не только это, но я также включил фигурные скобки для структур управления и использовал отступ, чтобы показать, какой код появляется под каждой структурой.
Ваше собственное представление о читаемом коде может немного отличаться от этого, но я бы поспорил, что каждый PHP-кодер может легко понять, что происходит во втором примере. Первый пример, однако, требует дополнительного времени для понимания. Пожертвование лишними строками и пробелами внесет заметный вклад в макет кода. Разрабатывая стандарты кодирования, постарайтесь обеспечить, чтобы они позволили кому-либо в будущем разрабатывать код!
Разные стандарты
Пример кода PHP и модули Pear (и т. Д.) Обычно используют стандарты кодирования Pear , которые немного отличаются от метода, который я использовал выше.
У меня есть свои собственные стандарты кодирования, которые я принял из стандартов кодирования phpBB, потому что мне понравилось, как они были написаны. Например, в моих собственных стандартах я поставил скобки для структур управления на новую строку:
if (condition) { get_user($id, $username, $key); }
Но в стандарте Pear первая скобка находится на той же строке, что и условие (условие):
if (condition) { get_user($id, $username, $key); }
Все стандарты, которые вы выбираете, зависят от личных предпочтений и от того, что вам проще всего кодировать и читать. Для начала я включил копию моих собственных стандартов для загрузки . Удачного кодирования!