21 ошибка программиста PHP, часть 2

Стерлинг Хьюз. Следующие 7 ошибок (#14-8) относятся к "серьёзным". Они ведут к ещё более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным.21 ошибка программиста PHP, часть 2 Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно. Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP. В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от некритических до смертельных. Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые маленькие хитрости, накопленные за многие годы практики программирования. Эта серия статей предназначена для тех программистов на языке PHP, которые хотят избежать наиболее общих ошибок в написании кода. Читатель, как минимум, должен знать общий синтаксис PHP, а также весьма желателен некоторый опыт использования языка на практике. Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно . Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP. В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от "некритических" до "смертельных". Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые "маленькие хитрости", накопленные за многие годы практики программирования. Часть 1: Описываются 7 "детских" ошибок (#21-15, в обратном порядке, в соответствии со степенью серьёзности по нашей классификации). Такие ошибки не вызывают серьёзных проблем, но приводят к уменьшению эффективности работы программы, а также выражаются в громоздком трудночитаемом коде, в который, к тому же, трудно вносить изменения. Часть 2: Следующие 7 ошибок (#14-8) относятся к "серьёзным". Они ведут к ещё более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным. Часть 3: Описания семи, последних, "смертельных" ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности. 14. Пренебрежение правилами присвоения имён Одна из наиболее серьёзных ошибок программиста - непродуманная система именования переменных проекта. Нередко приходится тратить уйму времени на разбор кода только потому, что автор вдруг решил ввести в программу переменные . Речь ведётся о реальном проекте, где не менее реальный программист решил все переменные проекта назвать именами героев мультсериала "Flinstones" (Это не шутка). То как вы назовёте переменные и функции программы, определит во многом читаемость её кода. Наиболее распространёнными ошибками являются имена: слишком короткие или наоборот, чрезмерно длинные; замедляющие разбор и чтение кода (особенно это касается имён функций). В PHP имена переменных регистрозависимы, то есть - две записи в списке переменных скрипта. Однако некоторые программисты активно пользуются этим и производят на свет переменные с совершенно одинаковыми именами, но использующими буквы разных регистров. Это отвратительная привычка. Регистр букв никогда не должен быть единственным отличием двух переменных. Каждая переменная на своём поле действия должна иметь уникальное имя. Для обозначения переменных многие программисты используют одним им понятные аббревиатуры. О чём впоследствии сильно жалеют, ибо смысл сокращения затерялся во времени своего создания. Имя переменной должно отражать характер её значения, то есть содержания и обозначаться полными словами или общепонятными сокращениями. С другой стороны, наблюдаются случаи злоупотребления длинными именами. Наиболее общее правило: имя переменной должно состоять максимум из двух слов. Разделить эти два слова мы можем, поставив understrike (то есть "_") или написав второе слово с заглавной буквы. Пример #1. Положительный. <?php ,  ,  ,  ,  ,  ,  ?> Пример #2. Отрицательный. Теперь рассмотрим несколько преувеличенные примеры того, как не следует присваивать имена переменным: <?php ,  ,  ,  ,  ,  ,  ?> Все правила, применяемые для имён переменных, годятся и для функций. Однако в случае с функциями, грамматические реалии имеют большее значение. Помните, что в PHP все функции, встроенные или определённые разработчиком, - регистронезависимы . Функции в PHP можно сравнить с какими-либо действиями, совершаемыми в реальном мире. Таким образом, имена функций должны отражать эту направленность на действие, то есть выражаться глаголами. Причём лучше в настоящем времени. В качестве примера рассмотрим функцию, генерирующую Гауссовы случайные числа. Предполагается, что из её имени мы должны понять, какая именно формула используется в генерации числа. Вот так: . Обратите внимание на использование глагола в имени функции. Именно глагол помещает функцию в правильный контекст: <?php ,  ,  ?> Для сравнения, другой пример: <?php ,  ,  ?> Видите разницу? Во втором примере для обозначения действия использовано существительное. И если назначение функции ещё прослеживается, название затрудняет чтение кода. Мораль: используйте глаголы! 13. Непродуманная работа с данными: бд и sql Забавно иногда наблюдать, сколько разных уловок находят люди для организации доступа к базам данных и получения выборки результатов. Среди прочих особенно выделяются комбинации из веток , циклов do..while , множественных запросов и вызовов функции . Чем , на их взгляд, они занимаются? Код, основанный на методе научного тыка, говорит о недостаточно ясно определённой организации работы с БД. Те, кто прилагают все свои усилия на написание кода, а не на написание правильного кода, рискуют больше потерять, чем заработать. Некорректная выборка данных - яркий тому пример. Некоторые программисты не уделяют достаточно времени на тщательное продумывание этого момента. Естественно, в реальной жизни может и не оказаться того "единственно верного" способа выборки данных, но всегда найдётся тысяча "неверных", это точно. Один из PHP-исходников предлагал следующий способ получения выборки из БД (приведённый ниже код в проекте находится после сгенерированных SQL <?php if (!( ?> Примечание: является дескриптором выборки или указателем на неё. Другими словами, был произведён запрос и получено определённое множество рядов. Примеры демонстрируют методы эффективной обработки этого множества. проверка на "ноль рядов" - это попытка получить хотя бы один. полученные данные не хранятся в ассоциативном массиве. , данный кусок кода предлагает косвенную проверку выборки на наличие хотя бы одного ряда данных. Но ведь существует прямой способ - это подсчёт количества рядов в выборке , как показано ниже: <?php ?> Избавляемся от do..while Прежде всего, исчезает необходимость в использовании давно уже поднадоевшего do..while , ибо для проверки на "ноль рядов" функция , и указатель по-прежнему установлен на начало. В PHP Source как-то был представлен подобный фрагмент кода. Если выборка не была нулевой, то функция внутри условного блока доставляла первый ряд. Для получения остальных приходилось прибегать к do..while , потому что получение ряда из выборки ("to fetch" - принести, доставить// Прим. перев.) смещает указатель в ней. Таким образом, сначала вам придётся обработать уже полученный ряд ("do"), только потом получить второй ряд и так далее. do..while так провинился? do..while помещён только один оператор: простой вывод. Теперь представим, что там может оказаться не один, а десять операторов. Тогда редактору кода придётся искать условие после и целого блока действий внутри цикла. Занятие не из приятных. обычно располагается в начале блока, а не в конце его. Поэтому редактору кода нужно будет уделять этому особое внимание при чтении, чтобы не спутать цикл do..while с предварительным условием while обычного цикла. В случае получения нулевой выборки, функция делает именно то, что вам нужно сделать: : "При попытке получить первый ряд не найдено ни одного ряда. Это может означать, что в данной выборке их нет ". : "Количество рядов в выборке равно нулю ". Но как это отражается на написании кода? Рассмотрим следующий пример, где операторы внутри условия записаны псевдокодом: if(!($row = sql_fetch_row($result))){Print Error}: Получаем первый ряд из выборки. Если выборка пустая, то переменной $row приписываем 0; ноль логически выражается False; отсюда !(0)=True; выводим сообщение об ошибке. Иначе, если выборка не пустая, получаем первый ряд, приписываем его переменной не равно нулю, то есть True; !(True)=False; выходим на цикл do..while . Подсчёт рядов в выборке. Если их меньше или равно нулю, выводим сообщение об ошибке. Иначе - идём дальше. Итак, какое из двух выражений проще и быстрее понять? Безусловно, подсчёт рядов - более прямой и короткий путь. Каково всё же практическое преимущество второго способа? Невелика разница, что мы поместим внутри этого условия - многого тут не выиграть. Однако на протяжении 10 000 строк вашего кода продуманные , а потому просто и ясно изложенные идеи сэкономят кучу времени редактору кода (вот и первое преимущество). Есть и другие преимущества: разработка скриптов заметно ускоряется и становится более размеренной. Действительно, некоторые СУБД могут не поддерживать эту функцию. Отнесёмся с сочувствием ко всем владельцам таких систем. Им придётся проверять выборки "на ноль рядов" путем запроса первого ряда. Однако и здесь, рекомендуем использовать булевские переменные: <?php if (! ?> для получения рядов. Как результат своей работы эта функция возвращает лишь пронумерованный массив. Однако существует ещё и функция , которая возвращает два <?php ?> Примечание: Существуют разные точки зрения на целесообразность использования одинарных кавычек при вставке строковых аргументов. В приведённом примере (столбец name) и далее по статье они не используются. Какая из функций более удобна для разработчика? Ассоциативные массивы позволяют редактору кода ясно и однозначно понять, какая именно выборка из БД будет осуществляться в каждом конкретном случае. Например: <?php ?> Итак, функция имеет целую тонну недостатков. Однако, существует ситуация, где её можно поставить без всякого ущерба "прозрачности" кода: когда sql-запрос формируется пользователем. До настоящего момента мы рассматривали примеры с заранее известными запросами и определёнными разработчиком. Но иногда возникает необходимость в запросе, сформированном самим пользователем. В таких случаях разработчику неизвестно количество столбцов в выборке. <?php . ( ).  ].  ?> Ошибки SQL: запрашивается не то, что нужно Практика показывает, что обра

Hosted by uCoz