Новым сегодня является пост о курении слишком много PHP, озаглавленный Шесть смертельных грехов PHP, на этой неделе … Статья дает краткий список советов для разработчиков PHP о том, почему им определенно следует избегать в своем коде.
Одна из записей называется Каждая переменная должна где-то начинаться . В предыдущем сообщении в блоге я упомянул, как неприятно было пытаться прочитать какой-то код и спрашивать себя: «Откуда эта переменная ?!». Алан помечает языковые конструкции PHP, такие как extract и eval, как «злые», потому что они маскируют и запутывают код. Это не новость . Однако он делает правильное замечание — что использование этих типов ярлыков само по себе не является проблемой безопасности — проблема безопасности возникает, когда ваш код слишком сложен для понимания, и вы непреднамеренно вводите дополнительные проблемы.
Возьмите register_globals например. Функция register_globals сама по себе не является проблемой безопасности, но тот факт, что она усложняет понимание и анализ кода, может легко привести к дырам в безопасности всего кода. В руководстве по PHP говорится, что «register_globals будет внедрять (отравлять) ваши скрипты во всевозможные переменные», что означает, что «писать небезопасный код намного проще».
При разработке на PHP, следующие шаги могут быть сделаны, чтобы сделать ваш код легче для понимания.
Не делайте ваш код слишком сложным. Если у вас есть выбор между выполнением чего-либо в одной строке или выполнением в четырех строках, выберите тот, который легче читать и понимать, чем тот, который занимает меньше места. Используйте аналогичный подход к именованию переменных. Переменная с именем $ j намного сложнее, чем переменная с именем $ payment_customers.
Разбейте код на маленькие отдельные функции (или методы). Когда фрагмент кода находится внутри функции, он получает выгоду от области видимости локальной переменной этой функции. Если эта функция имеет длину от 20 до 30 строк (включая комментарии), она может поместиться на вашем экране одновременно, что позволяет очень легко увидеть, откуда поступает каждая переменная. Если вы хотите знать, где что-то было инициализировано, вам не придется уходить и делать это (или сдаваться и доверять этому), если все его объявление / инициализация происходят на одной странице, где оно используется. Конечно, использование глобального ключевого слова сводит на нет это преимущество.
Прокомментируйте свой код. Общий вопрос новичков в PHP (или новичков на любом языке): «Сколько комментариев я должен использовать?». На это нет правильного ответа, и опытные программисты, которые потратили некоторое время на поддержку кода других людей, вероятно, будут знать это лучше, чем большинство других. Я бы порекомендовал, чтобы для каждого метода или функции вы были уверены, что ясно, какой тип аргументов ожидается, какое возвращаемое значение, если оно есть, и все остальное, что необходимо знать о методе, чтобы использовать его. Цель и возвращаемое значение должны быть понятны из имени функции / метода, но для устранения каких-либо сомнений не помешает это прокомментировать. Если метод должен быть «приватным», вы должны указать это. Если метод должен вызываться статически, вы должны указать это. В дополнение к этому, вы должны вставлять встроенный комментарий каждый раз, когда вы делаете что-то несколько сложное. Стили комментирования — горячо обсуждаемая тема, также как и стили кодирования (пробелы или табуляции?). Одно можно сказать наверняка, что вы должны прокомментировать свой код. Комментирование вашего кода облегчает понимание того, как он работает, и, следовательно, облегчает его последующий просмотр и гарантирует его безопасность.
К сожалению, много сложного для понимания кода является результатом лени или нереальных сроков. Имейте в виду, что независимо от текущей спецификации проекта, она, вероятно, изменится в будущем, и когда это произойдет, кто-то изучит ваш код и попытается изменить его направление и цель. Если код не требует пояснений, его будет гораздо проще изменить, и с меньшей вероятностью это создаст новые проблемы безопасности.
Убедиться в том, что ваш код легко читать и понимать, — это первый и, на мой взгляд, самый важный шаг к написанию безопасного кода.