21 ошибка программиста php


Содержание

Библиотека Интернет Индустрии I2R.ru

Малобюджетные сайты.

Продвижение веб-сайта.

Контент и авторское право.

Учебник РНР на русском

Этот учебник состоит в основном из справочника по функциям, но содержит также справочник по языку, разъяснения по некоторым основным возможностям языка PHP и другую сопутствующую информацию.

Автоматическое построение форм различной сложности и отправка их письмом с аттачами произвольного количества

Все сталкивались с тривиальной задачей — создание формы для отправки по e-mail. Обычно не возникает никаких проблемм. Но и работа эта не столь интересна и увлекательна. Простая рутина. Возникает идея создать программу, которая автоматизировала бы этот процесс.

Пишем на PHP

Я предлагаю вам совершить небольшой экскурс в язык запросов SQL. Это необходимо по двум причинам. Во-первых, не хочу, чтобы вы смотрели на SQL-фрагменты последующих скриптов как парнокопытные животные на только что построенное заградительное сооружение. А во-вторых, мне хочется донести до вас красоту этого языка, скрытую в его простоте и «человечности».

Пишем на PHP

К моему глубокому изумлению, обнаружилось, что очень многие программисты на том же perl продолжают игнорировать PHP только потому, что не могут найти помощи в освоении нового языка. Действительно, perl — очень распространенный и очень удобный язык. Но во многих случаях гораздо удобнее, быстрее и функциональнее писать на PHP.

Класс для постраничной навигации по результатам SQL-запроса (cookbook, англ.)

Код генерации кнопок «следующие/предыдущие записи», оформленный в виде класса PHP. Поддерживаются как mySQL, так и PostgreSQL (при генерации SQL-запроса учтены различия в синтаксисе LIMIT).

Поисковые машины и ужасные ссылки (англ.)

Решение проблемы индексации динамических сайтов поисковиками за счет отказа от передачи параметров в строке запроса (query string). Предлагается использовать директиву Apache «ForceType» и передавать параметры в виде виртуальных «подкаталогов».

PHP — язык программирования для Интернета

Вы вышли за рамки статических www-страниц? Вам требуется обрабатывать html-формы? Вы хотите сделать интефейс с базой данных через веб? Электронный магазин? Счетчик с подробной статистикой или опрос посетителей вашего сайта? Есть множество программ, работающих через интерфейс CGI, как правило, написанных на языке Perl, но сегодня существуют и другие возможности.

Сетевые функции PHP (Обзор)

Отправка почты из PHP, работа с HTTP, DNS, TCP/UDP (используя сокеты) и логами syslogd (запись в /etc/messages и проч). Примеры кода с комментариями автора.

Что такое PHP-NUKE или Web-портал за 15 минут

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

PHP-шаблоны или, как помирить программиста с верстальщиком

Современный Web-сайт — это продукт совместного труда дизайнера, программиста, верстальщика и контентщика. При разработке HTML протокола такое разделение труда не предполагалось. При необходимости динамического изменения фрагментов документа такое решение проблемы трудоемко. А для отображения результатов запроса поисковых серверов — это просто недопустимо.

Архитектурные решения на PHP (aнгл.)

Приложение объектно-ориентированного подхода к реализации многоуровневой архитектуры в PHP-скриптах. Описывается используемая автором реализация идей абстракции PHP-кода от HTML и базы данных.

Cессии PHP4 (Обзор)

Сессии позволяют сохранять значение переменных между страницами, избавляя программиста от ручной установки cookie или скрытых полей формы. Типичное применение сессий — авторизация (запоминание логина/пароля или факта залогиненности пользователя).

Оптимизация программ на PHP

Не используйте интерполяцию переменных в строках, заключайте строки в кавычки, используйте preg_match() вместо eregi(), перебирайте ассоциативные массивы foreach. Серия тестов, показывающая оптимальный с точки зрения производительности способ выполнить ту или иную операцию.

Независимость от базы данных в PHP (aнгл.)

Применение класса DB — унифицированного интерфейса к базам данных из библиотеки PEAR.

21 ошибка программиста PHP. Часть II

Перевод статьи с zend.com. Наиболее характерные ошибки при использовании PHP, от «некритических» до «смертельных». Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые «маленькие хитрости», накопленные за многие годы практики программирования.

21 ошибка программиста PHP. Часть I

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

Полоса новостей на PHP с использованием JavaScript и слоев (Сборник рецептов)

Импорт новостей с удаленного сайта на примере Gazeta.ru, с изменением внешнего вида. Примеры кода.

Apache & PHP — удобные технологии

Соединение Apache и PHP в заголовке данной статьи не случайно. Именно связка этих двух технологий на данный момент представляет собой наиболее удобное решение для небольших и средних по размеру сайтов. Для начала мы совершим экскурс в историю и проследим, каким путем шло развитие серверного программирования, а потом вернемся в день сегодняшний — попробуем установить на локальном компьютере версии Apache и PHP для Windows.

Импорт информации с удаленного сайта (Сборник рецептов)

Скрипт импорта погоды с Yahoo!. Результатом работы является прогноз на 5 дней для любого, интересующего Вас города, выводимый в виде, который нравится именно Вам.

Программирование на PHP: Вступление

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

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

Название 21 ошибка программиста php, часть 3
страница 1/11
Дата конвертации 26.04.2013
Размер 65.87 Kb.
Тип Тексты

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

Описания семи, последних, «смертельных» ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности


Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно.

Как правило, дело в недостаточной практике программирования.
Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP.

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

Часть третья

7 «смертельных» ошибок


  • href=»4.php#Audience»>Целевая аудитория
  • href=»4.php#Intro»>Введение

  • href=»4.php#7″>7.
    Программирование методом «вырезать-вставить»: неверный подход
  • href=»4.php#6″>6.
    Отсутствие в проекте технических директив
  • href=»4.php#5″>5.
    Отсутствие экспертной оценки программы
  • href=»4.php#4″>4.
    «Латание» проекта
  • href=»4.php#3″>3.
    Исключение конечного пользователя из процесса разработки
  • href=»4.php#2″>2.
    Отсутствие плана
  • href=»4.php#1″>1.
    Сорванные сроки
  • href=»4.php#summ»>резюме
  • href=»2.php»>21
    ошибка программиста PHP, часть 1
  • href=»3.php»>21
    ошибка программиста PHP, часть 2

  • name=audience>

    Целевая аудитория


    Введение

    Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно .

    Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений.
    Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP.

    В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от «некритических» до «смертельных». Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые «маленькие хитрости», накопленные за многие годы практики программирования.

    Часть 1: Описываются 7 «детских» ошибок (#21-15, в обратном порядке, в соответствии со степенью серьёзности по нашей классификации). Такие ошибки не вызывают серьёзных проблем, но приводят к уменьшению эффективности работы программы, а также выражаются в громоздком трудночитаемом коде, в который, к тому же, трудно вносить изменения.

    Часть 2: Следующие 7 ошибок (#14-8) относятся к «серьёзным». Они ведут к ещё более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным.

    Часть 3: Описания семи, последних, «смертельных» ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности.

    7. Программирование методом «вырезать-вставить»: неверный подход

    Некоторым новичкам свойственно копировать чужой код, например скрипты проверки адресов, отправки почты, обработчики форм. Результатом такой деятельности является мешанина операторов, хоть и криво, но делающая своё дело.

    И если при всех оптимальных условиях код и будет работать, то при настоящей проверке обязательно свалится. Причём латание «дыр» никогда не сделает ваш код:


    • расширяемым: программа будет выглядеть как набор обрывков кода сляпанных вместе. Попросите опытного программиста что-либо изменить в таком скрипте, и он почти наверняка предпочтёт написать свой. Нечитаемый код — нерасширяемый код.
    • безопасным: вы вставляете в свой проект код чужого человека; при этом вы точно не знаете, что же именно код делает. Задумайтесь над этим. А что если код содержи подложный системный вызов, который сносит все файлы с вашего жёсткого диска? Кроме того, один и тот же код не может быть одинаково защищён и безопасен для разных систем. Ну и, наконец, вы просто копируете чужие ошибки.
    • быстрым: если вы собираете код из кусочков разных скриптов, не ждите от него быстрой работы. Ибо в этом случае логическое развитие скрипта попросту отсутствует; а всем известно, что в основе быстродействия скрипта лежит его логика.

    21 ошибка программиста php

    micha5 (Tale quale | 7827 )
    26.4.2009, 14:41

    Эта серия статей
    предназначена для
    тех программистов
    на языке PHP,
    которые хотят
    избежать наиболее
    общих ошибок в
    написании кода.
    Читатель, как
    минимум, должен
    знать общий
    синтаксис PHP, а
    также весьма
    желателен некоторый
    опыт использования
    языка на практике.
    ©
    Скачать.jar-(64.86kb)
    ©
    Скачать.txt-(41.6kb)
    ©
    Цитировать

    Как правильно организовать обработку ошибок на PHP?

    Ошибки в лог надо писать все

    Вот простой быдлокодинг логирования ошибок. В лог попадает абсолютно всё, даже «засобаченное».

    Самому туда посылать ошибки можно функцией trigger_error()

    ‘; > else < // log error // file, database, whatever >> set_error_handler(‘errhandler’, error_reporting()); set_exception_handler(‘exceptionHandler’);

    >> Если ошибка идет в лог, то можно и не знать о ее существовании
    Таким людям логи не нужны вообще.

    >>Получается, что нужно периодически просматривать лог-файл?
    Сделайте уведомления себе на почту.

    Нормальный сайт требует поддержки все равно какой-никакой.

    Семь основных ошибок PHP программиста

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

    Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно.

    Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP.


    В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от «некритических» до «смертельных». Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые «маленькие хитрости», накопленные за многие годы практики программирования.

    Часть 1: Описываются 7 «детских» ошибок (#21-15, в обратном порядке, в соответствии со степенью серьёзности по нашей классификации). Такие ошибки не вызывают серьёзных проблем, но приводят к уменьшению эффективности работы программы, а также выражаются в громоздком трудночитаемом коде, в который, к тому же, трудно вносить изменения.

    Часть 2: Следующие 7 ошибок (#14-8) относятся к «серьёзным». Они ведут к ещё более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным.

    Часть 3: Описания семи, последних, «смертельных» ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности.

    14. ПРЕНЕБРЕЖЕНИЕ ПРАВИЛАМИ ПРИСВОЕНИЯ ИМЁН

    Одна из наиболее серьёзных ошибок программиста — непродуманная система именования переменных проекта. Нередко приходится тратить уйму времени на разбор кода только потому, что автор вдруг решил ввести в программу переменные $fred и $barney вместо ожидаемых $email и $name. Речь ведётся о реальном проекте, где не менее реальный программист решил все переменные проекта назвать именами героев мультсериала «Flinstones» (Это не шутка). То как вы назовёте переменные и функции программы, определит во многом читаемость её кода. Наиболее распространёнными ошибками являются имена:

    • слишком короткие или наоборот, чрезмерно длинные;
    • не связанные по смыслу с контекстом программы;
    • не учитывающие регистрозависимость;
    • замедляющие разбор и чтение кода (особенно это касается имён функций).

    В PHP имена переменных регистрозависимы, то есть $user и $User — две записи в списке переменных скрипта. Однако некоторые программисты активно пользуются этим и производят на свет переменные с совершенно одинаковыми именами, но использующими буквы разных регистров. Это отвратительная привычка. Регистр букв никогда не должен быть единственным отличием двух переменных. Каждая переменная на своём поле действия должна иметь уникальное имя.

    Слишком короткие имена

    Для обозначения переменных многие программисты используют одним им понятные аббревиатуры. О чём впоследствии сильно жалеют, ибо смысл сокращения затерялся во времени своего создания. Имя переменной должно отражать характер её значения, то есть содержания и обозначаться полными словами или общепонятными сокращениями.

    Слишком длинные имена

    С другой стороны, наблюдаются случаи злоупотребления длинными именами. Наиболее общее правило: имя переменной должно состоять максимум из двух слов. Разделить эти два слова мы можем, поставив understrike (то есть «_») или написав второе слово с заглавной буквы.

    Пример #1. Положительный.

    Как правильно присваивать имена переменным:

    $username = ‘sterling’;
    $password = ‘secret’;
    $teachers = array (‘Sadlon’,
    ‘Lane’,
    ‘Patterson’,
    ‘Perry’,
    ‘Sandler’,
    ‘Mendick’,
    ‘Zung’);
    foreach ($teachers as $teacher);

    Пример #2. Отрицательный.

    Теперь рассмотрим несколько преувеличенные примеры того, как не следует присваивать имена переменным:

    $username_for_database = ‘sterling’;
    $guMbi = ‘secret’; // for the $password
    $thelastnamesofteachers = array (‘Sadlon’,
    ‘Lane’,
    ‘Patterson’,
    ‘Perry’,
    ‘Sandler’,
    ‘Mendick’,
    ‘Zung’);
    foreach ($thelastnamesofteachers as
    $TeaChER);

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

    Помните, что в PHP все функции, встроенные или определённые разработчиком, — регистронезависимы.

    Функции в PHP можно сравнить с какими-либо действиями, совершаемыми в реальном мире. Таким образом, имена функций должны отражать эту направленность на действие, то есть выражаться глаголами. Причём лучше в настоящем времени.

    В качестве примера рассмотрим функцию, генерирующую Гауссовы случайные числа. Предполагается, что из её имени мы должны понять, какая именно формула используется в генерации числа. Вот так: generate_gaussian_rand().

    Обратите внимание на использование глагола в имени функции. Именно глагол помещает функцию в правильный контекст:

    Для сравнения, другой пример:

    Видите разницу? Во втором примере для обозначения действия использовано существительное. И если назначение функции ещё прослеживается, название затрудняет чтение кода.

    Мораль: используйте глаголы!

    13. НЕПРОДУМАННАЯ РАБОТА С ДАННЫМИ: БД И SQL

    Забавно иногда наблюдать, сколько разных уловок находят люди для организации доступа к базам данных и получения выборки результатов. Среди прочих особенно выделяются комбинации из веток if, циклов do..while, множественных запросов и вызовов функции sql_result() внутри цикла for. Чем, на их взгляд, они занимаются? Код, основанный на методе научного тыка, говорит о недостаточно ясно определённой организации работы с БД. Те, кто прилагают все свои усилия на написание кода, а не на написание правильного кода, рискуют больше потерять, чем заработать. Некорректная выборка данных — яркий тому пример. Некоторые программисты не уделяют достаточно времени на тщательное продумывание этого момента. Естественно, в реальной жизни может и не оказаться того «единственно верного» способа выборки данных, но всегда найдётся тысяча «неверных», это точно. Ошибки в организации выборки данным можно разделить на три класса:

    • неправильное использование функций обращения к БД
    • ошибки SQL: запрашивается не то, что нужно
    • обработка результатов выборки средствами PHP

    Неправильное использование функций обращения к БД

    Один из PHP-исходников предлагал следующий способ получения выборки из БД (приведённый ниже код в проекте находится после сгенерированных SQL-запросов):

    if (!($row = sql_fetch_row ($result))) <
    print «Ошибка: не найдено ни одного ряда»;
    exit;
    >
    do <
    print «$row[0]: $row[1]\n
    \n»;
    >
    while ($row = sql_fetch_row ($result));

    Примечание: в данном и последующих примерах $result является дескриптором выборки или указателем на неё. Другими словами, был произведён запрос и получено определённое множество рядов. Примеры демонстрируют методы эффективной обработки этого множества. В этом отрезке кода есть две ошибки: проверка на «ноль рядов» — это попытка получить хотя бы один. полученные данные не хранятся в ассоциативном массиве.

    Проверка на «ноль рядов» ($result): неправильный подход

    Задействовав функцию sql_fetch_row(), данный кусок кода предлагает косвенную проверку выборки на наличие хотя бы одного ряда данных. Но ведь существует прямой способ — это подсчёт количества рядов в выборке $result функцией sql_num_rows(), как показано ниже:

    Избавляемся от do..while

    Прежде всего, исчезает необходимость в использовании давно уже поднадоевшего do..while, ибо для проверки на «ноль рядов» функция sql_num_row() не выдёргивает первый рядв $row, и указатель по-прежнему установлен на начало.

    В PHP Source как-то был представлен подобный фрагмент кода. Если выборка не была нулевой, то функция sql_fetch_row() внутри условного блока доставляла первый ряд. Для получения остальных приходилось прибегать к do..while, потому что получение ряда из выборки («to fetch» — принести, доставить// Прим. перев.) смещает указатель в ней. Таким образом, сначала вам придётся обработать уже полученный ряд («do»), только потом получить второй ряд и так далее.

    Так чем же do..while так провинился?

    • в данном примере внутри цикла do..while помещён только один оператор: простой вывод. Теперь представим, что там может оказаться не один, а десять операторов. Тогда редактору кода придётся искать условие while после оператора do и целого блока действий внутри цикла. Занятие не из приятных.
    • условие while обычно располагается в начале блока, а не в конце его. Поэтому редактору кода нужно будет уделять этому особое внимание при чтении, чтобы не спутать цикл do..while с предварительным условием while обычного цикла.

    Делаем всё просто и понятно

    В случае получения нулевой выборки, функция sql_num_row() в отличие от sql_fetch_row() делает именно то, что вам нужно сделать:

    • действие sql_fetch_row(): «При попытке получить первый ряд не найдено ни одного ряда. Это может
    • означать, что в данной выборке их нет».
    • Действие sql_num_row(): «Количество рядов в выборке равно нулю».


    Но как это отражается на написании кода?

    Рассмотрим следующий пример, где операторы внутри условия записаны псевдокодом:

    • if(!($row = sql_fetch_row($result))):
    • Получаем первый ряд из выборки.
    • Если выборка пустая, то переменной $row приписываем 0; ноль логически выражается False; отсюда
    • !(0)=True; выводим сообщение об ошибке.
    • Иначе, если выборка не пустая, получаем первый ряд, приписываем его переменной $row; $row не равно
    • нулю, то есть True; !(True)=False; выходим на цикл do..while.
    • If(sql_num_rows($result)

    Получение рядов данных: правила эффективной работы

    Вторая проблема нашего кода — это использование функции sql_fetch_row() для получения рядов. Как результат своей работы эта функция возвращает лишь пронумерованный массив. Однако существует ещё и функция sql_fetch_array(), которая возвращает два массива: пронумерованный и ассоциативный:

    $row = sql_fetch_array ($result);
    print $row[1]; // Второй столбец
    print $row[name]; // Столбец name — имя

    Примечание: Существуют разные точки зрения на целесообразность использования одинарных кавычек при вставке строковых аргументов. В приведённом примере (столбец name) и далее по статье они не используются.

    Какая из функций более удобна для разработчика? Ассоциативные массивы позволяют редактору кода ясно и однозначно понять, какая именно выборка из БД будет осуществляться в каждом конкретном случае. Например:

    Итак, функция sql_fetch_row() имеет целую тонну недостатков. Однако, существует ситуация, где её можно поставить без всякого ущерба «прозрачности» кода: когда sql-запрос формируется пользователем.

    До настоящего момента мы рассматривали примеры с заранее известными запросами и определёнными разработчиком. Но иногда возникает необходимость в запросе, сформированном самим пользователем. В таких случаях разработчику неизвестно количество столбцов в выборке.

    Здесь для их эффективной обработки полезно использовать функцию sql_fetch_row() в сочетании с count():

    Ошибки SQL: запрашивается не то, что нужно

    Практика показывает, что обработка выборки из БД средствами PHP — тоже является ошибкой. Бывали случаи, когда для простого поиска по 2Мб БД программисты использовали PHP, а потом возмущались его медлительностью. А делать выборку «весом» в два метра занимает целую вечность.

    Язык Структурированных Запросов (SQL) был специально разработан для запросов и получения данных из таблиц в БД. Идея языка заключается в отсеивании данных ненужных вам (средствами SQL) и получении только тех, которые вам действительно необходимы для дальнейшей обработки (например, средствами PHP).

    Если вы заметили, что получаете в выборке данных, больше, чем вам нужно, это верный признак недоработанных SQL-запросов.

    Классический пример эффективного применения SQL-запросов — использование условия WHERE в синтаксисе SQL.

    Рассмотрим пример кода, производящего выборку и выводящего список имён и телефонов всех пользователей с id равным 5:

    Данный код имеет следующие недоработки: для поиска по всей БД используется PHP; при работе с БД малого размера на это можно и не обращать внимания, но с ростом БД вы обязательно заметите резкое падение скорости работы скриптов.

    Выход прост: включите в SQL-запрос условие WHERE:

    $statement = «SELECT name, phone FROM samp_table»;
    $statement .= » WHERE «;

    WHERE позволит применить более строгие критерии выборки. Фильтром в данном случае будет являться значение аргумента. В нашем примере это » >

    Получив нужную вам выборку, вы используете PHP для простого вывода результатов:

    if (@sql_num_rows ($result) != 1) <
    die («Получено неверное количество рядов»);
    >
    $row = @sql_fetch_array ($result);
    print «Имя: $row[name]\n
    \n»;
    print «Телефон: $row[phone]\n
    \n»;

    Обработка результатов выборки средствами PHP

    Нередко программист намеренно не сортирует выборку при запросе, перекладывая эту работу на PHP. Такой подход неэффективен, ибо сортировка средствами SQL проходит намного быстрее, чем в PHP.

    Для сортировки результатов рекомендуем применять синтаксис SQL (ORDER BY), а не PHP-функцию ksort().

    Рассмотрим пример использования ksort() для сортировки выборки по имени (name):

    $statement = «SELECT name, email, phone FROM some_table «;
    $statement .= «WHERE name IS LIKE ‘%baggins'»;
    $result = @sql_db_query ($statement, «samp_db», $conn);
    if (!$result) <
    die (sprintf («Ошибка [%d]: %s»,
    sql_errno (),sql_error ()));
    >
    while ($row = @sql_fetch_array ($result)) <
    $matches[ $row[name] ] = array ($row[email],
    $row[phone]);
    >
    ksort ($matches);

    Возникает вопрос: а почему бы ни провести сортировку результатов во время выборки? Это избавит нас от необходимости проходить по всему массиву с результатами дважды.

    Итак, убираем ksort() и исправляем SQL-запрос, добавив ORDER BY:

    $statement = «SELECT name, email, phone FROM some_table «;
    $statement .= «WHERE name IS LIKE ‘%baggins’ ORDER BY name»;

    12. СЛАБАЯ УСТОЙЧИВОСТЬ К ОШИБКАМ

    В природе существует огромное количество скриптов абсолютно не справляющихся с пользовательскими ошибками. Своим появлением такие скрипты обязаны программистам, которые не удосуживаются правильно распланировать будущий проект и определить все места возможных ошибок. Причём этим следует заняться до того, как скрипт был написан. Недоработки подобного рода приводят к сбоям программы, что чревато не только получением некорректных результатов, но и падением системы!

    Любой скрипт может «свалиться» при наступлении каких-либо «критичных» условий. Чтобы свести такой риск к минимуму всегда нужно:

    • проверять результаты вызова функций;
    • проверять результаты системных вызовов;
    • в файле php.ini устанавливать уровень error_reporting на E_ALL.

    Проверка результатов вызова функций

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

    В приведённом ниже примере на шестом витке цикла возникает ошибка «деление на ноль», поскольку $i наращивается на 1, а $j уменьшается на 1. На шестом проходе $i=$j=1.

    Проверка результатов системных вызовов

    При обращении к внешним файлам или процессам всегда проверяйте, всё ли работает корректно.

    Блестящий тому пример — проверка ответа системы при вызове функции sql_connect(). Стоит проверить этот ответ и убедиться, что подключение к БД действительно имело место. Если этого не сделать, то все запросы к БД могут не состояться, а некоторые данные могут быть утеряны; вы же будете пребывать в счастливом неведении.

    $conn = @sql_connect ($host, $user, $pass);
    if (!$conn) <
    die (sprintf («Ошибка [%d]: %s»,
    sql_errno (), sql_error ()));
    >

    Установка уровня error_reporting в файле php.ini на E_ALL

    Убедитесь, что PHP правильно сконфигурирован, то есть уровень error_reporting (отображение сообщений об ошибках) выставлено на наивысший уровень. При другой конфигурации, по крайней мере, на время отладки скриптов, многие ошибки типа «неверное регулярное выражение», «недопустимое значение» ускользнут от вашего внимания.

    Обратимся ещё раз к примеру, приведённому в части «Проверка результатов вызова функций». Предположим, что error_reporting выставлен не на максимум, а, скажем, на E_ERROR.

    Обратите внимание на то, как скрипт выполняет функцию do_math, но не сообщает об ошибке «деление на ноль», которая, однако, имела место (при $i=$j=0 вывода результата просто не было).

    Результат работы скрипта:


    Свои обработчики ошибок

    Как правило, PHP выдаёт сообщения об ошибках непосредственно в браузер и не позволяет разработчику подавить или перехватить их. Однако в PHP4 у вас появилась возможность перехвата таких сообщений с помощью функции set_error_handler().

    Функция set_error_handler() применяется для записи ошибок вашего скрипта. Теперь вы можете перехватывать все ошибки и программировать собственные обработчики — warning’и пользователей больше не побеспокоят.

    В следующем примере set_error_handler() назначает обработчиком по умолчанию функцию error_handler(). В \случае возникновения ошибки вызывается error_handler(), и встроенная функция error_log() регистрирует сбой в файле лога error_file.

    Если происходит ошибка класса E_ERROR, работа скрипта прекращается и выводится сообщение об ошибке.

    11. НЕОПРАВДАННОЕ ИСПОЛЬЗОВАНИЕ ООП

    Парадигма ООП — замечательный подход к написанию кода. У ООП есть множество неоспоримых преимуществ, самое значительное из которых — возможность использовать заново уже некогда написанный код. Однако все мы рано или поздно осознаём тот факт, что ‘PHP — не объектно-ориентированный язык’.

    Несмотря на то, что PHP имеет корректно работающую поддержку объектов, использовать объекты там, где можно без них обойтись — недальновидно и неэффективно. Причина? Дело в том, что поддержка парадигмы ООП в PHP реализована не в полном объёме.

    Несмотря на присутствие основных элементов, PHP всё-таки не хватает многих «продвинутых» функций (как защищённые члены или закрытые переменные), которые обязательны для «настоящих» объектно-ориентированных языков (например, Java, C++).

    Кроме того, поддержка объектов в PHP недостаточно отработана и не очень эффективна. Это означает, что использование парадигмы ООП может существенно снизить скорость выполнения программы.

    Примечание: Другими словами, скрипт, работающий на объектах будет исполняться медленнее, как код внутри eval() по сравнению с обычным кодом. Для более наглядных примеров, где использование ООП принимает какие-то уродливые формы, пришлось бы прибегнуть к продвинутым функциям концепциям PHP, некоторые из которых даже незадокументированы. Так что остановимся на этом.

    А что же мы сможем без ООП?

    Если вы пришли в PHP из Java или C++, где без объектов трудно создать что-либо более или менее серьёзное, то и в PHP вам будет трудно обходиться без них. Но будьте уверены, что серьёзные приложения могут быть написаны и методик и приёмов ООП (PHP был написан на C, а последний, как мы знаем, не поддерживает объектов).

    Итак, для тех, кто не привык обходиться без ООП, приведём альтернативные технологии написания связных и расширяемых приложений вне парадигмы ООП:

    • Создание API.
    • Разработка концепции именования (и работа в её рамках).
    • Группирование взаимосвязанных функций в один файл.

    Соотнесём код программы с тремя уровнями:

    • Первый — собственно рабочие функции.
    • Второй — API функции. Сюда входят функции для построения конкретного приложения.
    • Третий — само приложение:

    MortgageRate.php (Ипотечный Кредит):

    30000)
    return (3.2);
    elseif ($total > 50000)
    return (2.5);
    else
    return (1.7);
    >
    // Уровень второй — API функции
    // double calculate_mortgage_rate (int money, int time, int month)
    // Рассчитывает процентную ставку исходя из
    // суммы займа, времени погашения и интервала
    // выплат
    function calculate_mortgage_rate ($money, $time, $month)
    <
    $rate = _mort_find_interest_rate ($money) / 100;
    $money /= ($time / $month);
    return ($rate * $money) + $money;
    >
    ?>

    Разработка концепции именования и работа в её рамках.

    Один из самых неприятных моментов при разработке больших приложений — это конфликты пространства имён. Классы его сегментируют. Таким образом, разные классы могут:

    • иметь свойства с одинаковыми именами или
    • содержать в себе методы с одинаковыми именами.

    Например, класс Phillips и класс Normal могут одновременно содержать метод с именем screwdriver.

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

    Группирование взаимосвязанных функций в один файл

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

    Например, можно было бы все функции, связанные с общением с БД, собрать в файл DB.php.

    ООП, как и всё на свете, хорошо в меру

    Небольшая оговорка: эта глава была написана не для того, чтобы отговорить вас от использования ООП вообще. Скорее, это была попытка убедить вас не работать с PHP в режиме Java или C++, где ООП — решение номер один.

    Проведите тщательный анализ всех выгод и потерь, прежде чем применить объектный подход в PHP.

    10. НЕОПРАВДАННОЕ ИСПОЛЬЗОВАНИЕ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ

    Регулярные выражения — мощный инструмент для поиска и организации данных, как, например, проверка адреса электронной почты на корректность или поиск URL. Но в то же время регулярные выражения работают медленнее других функций PHP, предназначенных для более простых задач.

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

    Однако, в этом случае, используя тяжеловесный и медленный ereg_replace(), он потратил бы кучу драгоценного времени выполнения на задачу, с которой более лёгкая функция strtoupper() справилась бы намного быстрее $data = strtoupper ($data);

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

    Эти функции должен знать каждый

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

    strtoupper(); strtolower(); ucfirst(); strtr(); str_replace(); trim(); explode(); implode(); substr(); strcmp()

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

    9. ПРОГРАММИРОВАНИЕ НА PHP КАК НА ДРУГОМ ЯЗЫКЕ

    Многие приходят в PHP уже с большим опытом программирования в другом языке, как PERL, C, Java или (ну это ещё куда ни шло) ASP. И частенько «импортируют» техники и подходы, которые не всегда хорошо сочетаются с методиками PHP.

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

    При таком подходе очень часто на выходе мы получаем медленный и трудно поддерживаемый код. И такие случаи не редкость:

      «однострочники» PERL. PHP — язык мало приспособленный к так называемому методу-«всё в одной строке». Рекомендуем разбивать сложные хитросплетения комбинированных функций и представлять их в более структурированном виде.


    PHP
    $quote) <
    print «$name: «;
    print implode (» «, array_reverse (preg_split (‘//’,
    $quote)));
    print «\n»;
    >
    @fclose ($fp);
    ?>

  • Уклонение от встроенных функций: Многие PHP-программисты, пришедшие из C, кажется, не понимают того, что PHP содержит целую армию встроенных функций. Их цель — избавить вас от километровых скриптов. Если вы раньше писали на C, вам настоятельно рекомендуется изучить техническое описание PHP и узнать, какие функции PHP вам может предложить и тем самым облегчить вам жизнь.
  • Переименование стандартных функций PHP: некоторые программисты переименовывают стандартные функции PHP только для того, чтобы легче их запоминать. Это не только снижает скорость выполнения скрипта, но и затрудняет чтение кода.
  • Неоправданное использование ООП: PHP — не объектно-ориентированный язык, хотя некоторая поддержка объектов всё-таки имеется. И всегда стоит помнить, что использование функций поддержки ООП значительно снижает скорость выполнения скрипта.
  • 8. НЕДОСТАТОЧНОЕ ВНИМАНИЕ К ВОПРОСАМ БЕЗОПАСНОСТИ

    Пользователи никогда не будут работать по нашим правилам. Поэтому создание системы устойчивой и терпимой к ошибкам — целиком и полностью ответственность разработчиков, то есть нас.

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

    Пример: многие скрипты не используют встроенную PHP-функцию mail(), которая обеспечивает безопасную отправку почты. Вместо этого почта отправляется через программу sendmail с помощью popen(). Это делает код весьма неустойчивым к искажению данных и представляет собой «дыру» в безопасности системы (получателю можно отправить /etc/passwd).

    Перечислим наиболее распространённые «дыры», позволяющие искажать данные:

    • системные вызовы. Никогда нелишне повторить. Каждый раз нужно убедиться, что пользователь отправляет вам «безопасные» данные для системного вызова. НИКОГДА НЕ ДОВЕРЯЙТЕ ДАННЫМ, ПОЛУЧЕННЫМ ОТ ПОЛЬЗОВАТЕЛЯ. И ПРЕЖДЕ ЧЕМ ПОДСТАВИТЬ ИХ В СИСТЕМНЫЙ ВЫЗОВ ПРОВЕРЬТЕ ИХ.
    • регистрация пользователей. Если вы желаете получить корректные результаты, обязательно проверяйте полученные данные, причём, лучше если проверка будет состоять из нескольких этапов. Прежде всего, это проверка адреса электронной почты: убедитесь, что пользователь предоставил вам работающий аккаунт. Кроме того, стоит убедиться, что указанный возраст находится в определённых пределах. Вы можете быть совершенно уверены, что на нашей планете нет двухсотлетних товарищей, которые ещё способны сесть за компьютер.
    • приём номеров кредитных карточек. Некоторые программисты ограничиваются самыми простыми алгоритмами; их легко обмануть. Существуют крупные специализированные организации для проверки кредитных карточек; рекомендуем прибегать к их помощи или ресурсам и только потом решать, принята карточка или нет. НИКОГДА НЕ ПОЛАГАЙТЕСЬ ТОЛЬКО НА АЛГОРИТМЫ.

    Безопасность системных вызовов.

    Если возникает необходимость поместить полученные от пользователя данные в системный вызов, обязательно проверьте и перепроверьте их. Убедитесь, что данные, которые пользователь предоставил системе, не содержат «опасных» элементов и не взломают систему нежелательными командами. Для этого PHP предлагает специальную функцию EscapeShellCmd().

    Каждый раз при системном вызове с потенциально небезопасными данными, дезактивируйте их с помощью EscapeShellCmd():

    Примечание: дезактивация проходит путём подстановки бэкслэша («\») перед потенциально небезопасными для системы символами (а именно: #&;?’\»|*?

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

    Название 21 ошибка программиста php, часть 3
    страница 1/11
    Дата конвертации 26.04.2013
    Размер 65.87 Kb.
    Тип Тексты

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

    Описания семи, последних, «смертельных» ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности

    Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно.

    Как правило, дело в недостаточной практике программирования.
    Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP.

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

    Часть третья

    7 «смертельных» ошибок


    • href=»4.php#Audience»>Целевая аудитория
    • href=»4.php#Intro»>Введение

  • href=»4.php#7″>7.
    Программирование методом «вырезать-вставить»: неверный подход
  • href=»4.php#6″>6.
    Отсутствие в проекте технических директив
  • href=»4.php#5″>5.
    Отсутствие экспертной оценки программы
  • href=»4.php#4″>4.
    «Латание» проекта
  • href=»4.php#3″>3.
    Исключение конечного пользователя из процесса разработки
  • href=»4.php#2″>2.
    Отсутствие плана
  • href=»4.php#1″>1.
    Сорванные сроки
  • href=»4.php#summ»>резюме
  • href=»2.php»>21
    ошибка программиста PHP, часть 1
  • href=»3.php»>21
    ошибка программиста PHP, часть 2

  • name=audience>

    Целевая аудитория


    Введение

    Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно .

    Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений.
    Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf()или неправильное использование семантики PHP.

    В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от «некритических» до «смертельных». Наряду с анализом этих ошибок, представлены способы их избежания, а также некоторые «маленькие хитрости», накопленные за многие годы практики программирования.

    Часть 1: Описываются 7 «детских» ошибок (#21-15, в обратном порядке, в соответствии со степенью серьёзности по нашей классификации). Такие ошибки не вызывают серьёзных проблем, но приводят к уменьшению эффективности работы программы, а также выражаются в громоздком трудночитаемом коде, в который, к тому же, трудно вносить изменения.


    Часть 2: Следующие 7 ошибок (#14-8) относятся к «серьёзным». Они ведут к ещё более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным.

    Часть 3: Описания семи, последних, «смертельных» ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделённое как проекту в целом, так и коду программы, в частности.

    7. Программирование методом «вырезать-вставить»: неверный подход

    Некоторым новичкам свойственно копировать чужой код, например скрипты проверки адресов, отправки почты, обработчики форм. Результатом такой деятельности является мешанина операторов, хоть и криво, но делающая своё дело.

    И если при всех оптимальных условиях код и будет работать, то при настоящей проверке обязательно свалится. Причём латание «дыр» никогда не сделает ваш код:


    • расширяемым: программа будет выглядеть как набор обрывков кода сляпанных вместе. Попросите опытного программиста что-либо изменить в таком скрипте, и он почти наверняка предпочтёт написать свой. Нечитаемый код — нерасширяемый код.
    • безопасным: вы вставляете в свой проект код чужого человека; при этом вы точно не знаете, что же именно код делает. Задумайтесь над этим. А что если код содержи подложный системный вызов, который сносит все файлы с вашего жёсткого диска? Кроме того, один и тот же код не может быть одинаково защищён и безопасен для разных систем. Ну и, наконец, вы просто копируете чужие ошибки.
    • быстрым: если вы собираете код из кусочков разных скриптов, не ждите от него быстрой работы. Ибо в этом случае логическое развитие скрипта попросту отсутствует; а всем известно, что в основе быстродействия скрипта лежит его логика.

    21 ошибка программиста php

    Подписывайся на YouTube канал о программировании, что бы не пропустить новые видео!

    21 ошибка программиста PHP
    Автор: Стерлинг Хьюз
    Целевая аудитория
    Эта серия статей предназначена для тех программистов на языке PHP, которые хотят избежать наиболее общих ошибок в написании кода. Читатель, как минимум, должен знать общий синтаксис PHP, а также весьма желателен некоторый опыт использования языка на практике.
    Введение
    Одна из наиболее сильных сторон PHP является, одновременно, и его слабой стороной: PHP очень прост в изучении. Это привлекает многих людей; однако, несмотря на его кажущуюся простоту, не так-то просто научиться использовать этот язык правильно и эффективно.
    Как правило, дело в недостаточной практике программирования. Неопытные программисты становятся перед лицом необходимости создания сложных веб-приложений. Поэтому сплошь и рядом допускаются ошибки, которых избежал бы опытный программист, такие как необоснованное использование функции printf() или неправильное использование семантики PHP.
    В этой серии из трех статей представлены наиболее, по нашему мнению, характерные ошибки. Эти ошибки можно классифицировать по нескольким категориям, от «некритических» до «смертельных». Наряду с анализом этих ошибок представлены способы их избежания, а также некоторые «маленькие хитрости», накопленные за многие годы практики программирования.
    Часть 1: Описываются 7 «детских» ошибок (21-15 в обратном порядке, в соответствии со степенью серьезности по нашей классификации). Такие ошибки не вызывают серьезных проблем, но приводят к уменьшению эффективности работы программы, а также выражаются в громоздком трудночитаемом коде, в который, к тому же, трудно вносить изменения.
    Часть 2: Следующие 7 ошибок (14-8) относятся к «серьезным». Они ведут к еще более значительному уменьшению скорости выполнения кода, уменьшению безопасности скриптов; код становится еще более запутанным.
    Часть 3: Описания семи последних, «смертельных» ошибок. Эти ошибки концептуальны по своей природе и являются причиной появления ошибок, описанных в 1-ой и 2-ой частях статьи. Они включают и такие ошибки, как недостаточное внимание, уделенное как проекту в целом, так и коду программы, в частности.
    21. Неоправданное использование функции printf()
    Функция printf() предназначена для вывода форматированных данных.
    Например, ее следует использовать при необходимости вывода переменной в формате с плавающей запятой с определенной точностью, либо в любом другом случае, когда возникает необходимость изменения формата выводимых данных.
    Ниже приведен пример обоснованного применения функции printf(). В данном случае она используется для форматированного вывода числа «пи»:

    «Warning: Supplied argument is not a valid File-Handle resource in tst.php on line 4»

    <
    // Напечатаем каждое значение возраста

    Для чего здесь использована временная переменная?! Она просто не нужна:

    Встречаются также рекомендации приступая к программированию на PHP, первым делом заменять имена встроенных функций более привычными.
    Существует, как минимум, две причины этого не делать. Во-первых, и прежде всего, мы получаем менее читаемый код. Люди, читающие ваш код, увидят массу очевидно ненужных функций и будут сильно удивлены, почему же вами не использовались стандартные функции PHP.
    Ну и, наконец, это замедляет программу. Дело не только в необходимости обработки большего объема кода, но и в том, что для вызова такой пользовательской функции, требуется больше времени, чем для прямого вызова стандартной функции.

    Используйте стандартные функций языка!
    Иногда так трудно устоять! Ведь программист редко знает сразу весь набор функций — у него обычно нет времени запомнить их все. Почему бы просто не переименовать функцию? Но, повторимся, этого не следует делать в силу изложенных выше причин.
    Хорошо бы иметь под рукой справочник по функциям PHP (удобно использовать индексированную версию в формате PDF). И перед тем как написать какую-либо функцию, внимательно посмотреть — не существует ли она уже в списке стандартных функций.
    Но следует заметить, что в кодах программ можно встретить пользовательские функции, написанные еще до их введения в качестве стандартных (например, функции сравнения двух массивов). Это не означает, что вы обязательно должны переписать код и заменять их стандартными функциями.
    16. Клиентская часть программы не отделяется от серверной части
    Многие программисты рекомендуют объединять код HTML (интерпретируемый на стороне клиента) и код PHP (выполняемый сервером) в один большой файл.
    Для маленьких сайтов это, возможно, неплохо. Но, когда ваш сайт начнет расти, вы можете столкнуться с проблемами при необходимости добавить какие-либо новые функции. Такой стиль программирования приводит к очень «непослушному» и громоздкому коду.
    API функций
    Если вы собрались отделить код PHP от HTML кода, у вас есть два варианта. Один способ — — создать функции динамического формирования вывода и поместить их в нужное место на веб-странице.
    Например, так:
    index.php — код страницы

    site.lib — Сам код программы

    function print_body ()
    <
    global $site_info;
    print nl2br ($site_info->body);
    >

    function print_links ()
    <
    global $site_info;

    $links = explode («\n», $site_info->links);
    $names = explode («\n», $site_info->link_names);

    for ($i = 0; $i $names[$i]

    Очевидно, такой код лучше читаем. Еще одно преимущество использования этой концепции — возможность изменения дизайна без модификации самого кода программы.
    Плюсы использования API функций
    • Относительно чистый, ясный код
    • Быстрый код
    Минусы использования API функций
    • Не настолько наглядно как система шаблонов
    • Все-таки для модификации дизайна требуется некоторое знание PHP
    Система шаблонов
    Второй способ, используемый для разделения PHP и HTML кода, — использование шаблонов. В данном случае некоторые элементы дизайна заменяются пользовательскими тегами, а сама программа сканирует файл на предмет их наличия и заменяет их необходимой информацией.
    Пример использования шаблонов:

    Затем пишем программу, просматривающую код шаблона и при выводе заменяющую тэги вида %%SOME%% нужной информацией.
    Примечание: неплохой класс для использования его в системе шаблонов — FastTemplate, его можно скачать с http://www.thewebmasters.net/.

    Опубликовал Kest Октябрь 26 2008 15:46:29 · 1 Комментариев · 58030 Прочтений ·

    • Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •

    Страница 1 из 4 1 2 3 4 >
    Комментарии
    Михаил Ноябрь 24 2010 16:20:09
    По-моему статья не закончена.
    Добавить комментарий
    Рейтинги

    Рейтинг доступен только для пользователей.

    Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.

    Отлично! 50% [1 Голос]
    Очень хорошо 0% [Нет голосов]
    Хорошо 50% [1 Голос]
    Удовлетворительно 0% [Нет голосов]
    Плохо 0% [Нет голосов]
    Гость

    Вы не зарегистрированны?
    Нажмите здесь для регистрации.

    Забыли пароль?
    Запросите новый здесь .

    Как найти ошибку в своем коде?

    Быстрые рекомендации.
    1. Убедитесь, что вы видите сообщения об ошибках, если они возникают.
    Для этого надо добавить в начало скрипта 2 строчки
    ini_set ( ‘display_errors’ , 1 );
    error_reporting ( E_ALL );
    Хотя в некоторых случаях это всё равно не поможет. Тогда смотрите ошибки в логах веб-сервера.
    Ещё можно добавить в файл .htaccess строчку
    php_flag display_errors 1
    Обязательно убрать всех собак (@) из кода!
    Если апач выдаёт ошибку 500 — значит надо смотреть текст ошибки в логе ошибок веб-сервера.

    2. Если возникают проблемы с функциями MySQL (например «supplied argument is not a valid MySQL result resource») — это значит, что mysql_query() выполнилась с ошибкой. Чтобы всегда быть в курсе таких ошибок, функцию mysql_query надо вызывать так:

    $sql = «SELECT * FROM table» ;
    $res = mysql_query ( $sql ) or trigger_error ( mysql_error (). » in » . $sql );

    Если используется mysqli, то перед коннектом написать 1 строчку:
    mysqli_report ( MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT );

    Если используется PDO, то соединяться, как написано здесь: http://phpfaq.ru/pdo#connect

    3. При работе с изображениями, чтобы увидеть сообщение об ошибке, обязательно надо догадаться отключить вывод заголовка, говорящего браузеру, что дальше идет картинка.
    И, естественно, обращаться к скрипту напрямую, а не через тег !

    4. При проблемах в аплоаде в первую очередь смотрите массив $_FILES ( print_r ( $_FILES ); ). Описания ошибок из $_FILES[‘filename’][‘error’] есть в мануале.

    5. При проблемах во взаимодействии сервера и клиента (куки, сессии, запросы)- в обязательном порядке смотреть обмен HTTP заголовками

    6. Закомментируйте строчку с header(«Location:»), если ищете обшибку в обработчике POST запроса

    7. При отладке AJAX запросов смотрите ответ сервера в FireBug-e и его аналогах (кнопка F12 в любом браузере), вкладка Network — Preview.

    8. И САМОЕ ВАЖНОЕ: запуская скрипт, смотрите не то, что показывает браузер, а ИСХОДНЫЙ HTML код!.

    Получив сообщение об ошибке, вы можете его прочитать и исправить.
    Если не справились — пишите на форум. При этом КОПИРУЙТЕ сообщение об ошибке, и КОПИРУЙТЕ небольшой — 3-5 строк — кусок кода, на который указывает ошибка. Повторяю — КОПИРУЙТЕ! никакой отсебятины!

    Если вы всё равно не нашли ошибку — читайте дальше:

    Введение. Очень важное.
    Ты написал программу, а она не работает.
    Вариантов ты видишь немного — либо сидеть и пытаться умственным усилием обнаружить ошибку, в сотый раз просматривая код, либо пойти на форум и попросить, чтобы там тебе нашли ошибку.
    Самое интересное, что есть третий, в сто раз лучше первых двух.
    Этот способ называется «Отладка программы». По-английски — debug.
    Заключается он в том, чтобы заставить программу саму показать, где в ней ошибка.
    Это мало того, что получится быстрее, чем спрашивать на стороне — так зачастую это единственный способ решить проблему. Единственный.
    Я тебе сейчас открою страшный секрет. В мире НЕТ программистов, которые пишут код, как художники на Арбате — сел, наваял, отдал. Нету. И не будет.
    Процесс написания программы — циклический: Написал кусок кода — посмотрел, как работает. Если не работает — ищем ошибки. Работает — пишем дальше.
    Только так. Других вариантов нет.
    Больше того. В большинстве случаев совершенно бесполезно вываливать на форум свой код, и спрашивать — «В чём ошибка?». На форуме не сидят волшебники вперемешку с телепатами. И гадалок с прорицателями — тоже нет. Поэтому отгадывать, в чём, теоретически, может быть ошибка, никто не будет. Ошибку найти может только хозяин программы. На своём сервере. Со своими настройками и опечатками. Поэтому локализовать ошибку — найти место, где она происходит, определить тип ошибки — можно только самостоятельно. А вот исправить её на форуме помогут. Если не получится самому.

    Те, кто приходит к веб-программированию от дизайна, или от игр, или от нечего делать, просто не знают этой страшной тайны: Основное время программиста уходит не на написание кода. Основное время программиста уходит на поиск ошибок и отладку. Это не шутка. Это правда. И если вы решили заняться программированием, то вам придётся искать ошибки точно так же, как это делают все остальные.
    К сожалению, очень много людей приходит к PHP вообще без опыта программирования и, как следствие — никогда не слышали об отладке.
    А это и есть самое главное в программировании — умение искать ошибки.
    И мы с тобой сейчас будем учиться их искать.

    Программа не работает. Что можно сделать в этом случае?

    Сообщения об ошибках PHP.
    Самый твой большой помощник в деле отладки — это сам PHP. При возникновении любых проблем он сообщит тебе о них. То есть, в первую очередь ты должен убедиться в том, что если сообщение об ошибке есть — ты его увидишь.

    Пояснение: Очень многие люди не понимают, что такое сообщение об ошибке. В основном эти люди делятся на две категории. Первая считает, что сообщения об ошибках — это блажь разработчиков языка, надоедливый сервис, сделанный для того, чтобы программисту было не скучно. И избавляться от сообщений надо любыми доступными способами. Вторая категория не выросла из школьного возраста и воспринимает не смысл ошибки, а лишь сам факт. Принимают пхп за стервозного завуча, который ругает не по делу, а абстрактно, за то, что оболтус. То есть, факт появления ошибки вызывает у этих людей только негативные эмоции, а в смысл они даже не пытаются вчитываться.


    Это чудовищные заблуждения. Сообщения об ошибках — это ПОМОЩЬ! Это громадная помощь программисту. Как ей воспользоваться, мы рассмотрим ниже.

    Даже самый рабочий код, которому ты на 100% доверяешь, и который на соседней машине работает, как часы, может выдавать сообщение об ошибке. Причин тому может быть бесконечное множество. Это и такой распространенный случай, как отсутствие прав доступа к файлам, и такие экзотические, как запрещение провайдером выполнения самых распространенных и безобидных функций.

    Твоя задача — обеспечить интерпретатору возможность сообщить тебе об ошибке при возникновении оной.
    Ты должен быть уверен, что если выполнение программы вызывает ошибку, то ты эту ошибку увидишь.
    Что интерпретатору не запрещено сообщать тебе об ошибке.
    Что ты запросил все варианты вывода сообщения об ошибке.

    Во-первых, надо выяснить, выводятся ошибки на экран или пишутся в лог. Обычно, домашний, или тестовый сервер настраивается так, чтобы ошибки выводились на экран. Рабочий же сервер, с сайтом в публичном доступе ОБЯЗАТЕЛЬНО должен быть настроен так, чтобы ошибки не выводились на экран (поскольку посетителю они все равно ничего не скажут, а программист их не увидит), а писались в лог, где программист их увидит.
    Если ты не уверен, и не знаешь, где посмотреть, а ошибку найти надо срочно, то напиши в самом начале скрипта две строчки
    ini_set ( ‘display_errors’ , 1 );
    error_reporting ( E_ALL ^ E_NOTICE );
    Эти две строки заставят выводить сообщения обо всех критических ошибках на экран.
    Если никаких ошибок не выведется, надо написать
    error_reporting ( E_ALL );
    Это очень сильно поможет, показав несуществующие переменные и другие мелкие ошибки, которые обычно игнорируются, но от которых может зависеть работоспособность программы.
    ВАЖНО! В случае ошибки синтаксиса, по очевидным причинам, установка с помощью ini_set не сработает.
    Поэтому лучше на неё не надеяться, а либо исправить в php.ini (или в .haccess добавить строчку php_flag display_errors 1 ), либо искать ошибку в логе.

    Во-вторых, убедись, что в коде отсутствуют символы ‘@’ перед именами функций. Этот запрещает вывод сообщения об ошибке. Хорошенькое дело! Ты ошибку ищешь-ищещь, а сам же своей программе рот заткнул.

    Если ты уверен, что ошибка есть, но на экран она всё равно не выводится — найди лог ошибок веб-сервера. Обычно, это файл с названием error_log. Где он находится — надо посмотреть в документации или спросить в службе поддержки провайдера.

    При возникновении проблем с функциями mysql (supplied argument is not a valid MySQL result resource) под строкой, где произошла ошибка, обязательно надо вывести на экран mysql_error() и сам запрос — для визуального контроля и копирования на форум.

    При работе с изображениями, чтобы увидеть сообщение об ошибке, обязательно надо догадаться отключить вывод заголовка, говорящего браузеру, что дальше идет картинка.
    При аплоаде в первую очередь смотрите массив $_FILES.
    При проблемах во взаимодействии сервера и клиента — в обязательном порядке смотреть обмен HTTP заголовками
    И всегда смотрите не то, что показывает браузер, а ИСХОДНЫЙ HTML код!

    Допустим, сообщение об ошибке появляется, и ты его получил. Что делать дальше? Очень просто — прочесть и исправить. Если не хватает знания английского языка, то стоит либо воспользоваться переводчиком, либо взять значащую часть этого сообщения и запросить Google. 90% вероятности, что кто-то с такой ошибкой уже сталкивался, и ты тут же прочтешь ответ.
    Если же не нашел, то задай вопрос в форуме, точно скопировав небольшой (3-5 строк) кусок кода, в котором произошла ошибка, точно указав строку, о которой говорится в сообщении об ошибке, а так же — самое главное! — само сообщение об ошибке.
    Согласись, что с такой информацией тебе на форуме помогут гораздо скорее и качественней?

    Отладка и поиск ошибок в своем алгоритме.
    Но бывает так, что программа не вызывает ошибок, но все равно не работает, или работает не так, как надо.
    Тут уже виноват или алгоритм или какие-то внешние факторы.
    Однако и тут можно найти место, где происходит ошибка.
    Но только при одном условии.
    что ты четко представляешь, что делает твоя программа, каждая функция, каждая строка в ней. Потому, что если ты представляешь, то можешь предсказать, какие значения должны иметь переменные на каждом этапе выполнения.
    А дальше все ОЧЕНЬ просто!
    Во-первых, надо разделить программу на логические блоки.
    Допустим, скрипт выводит форму, получает ее, и записывает данные в базу. ТРИ шага! И в любом из них может быть ошибка, приводящая к тому, что данные в базу не записываются.
    Надо проконтролировать на каждом из участков — все ли переменные имеют то значение, которое ожидается.
    Программа ведь работает с переменными.
    Как проверить?
    Выводить все используемые переменные на экран! И визуально контролировать их содержимое.
    Всего-то лишь написать проблемных местах var_dump($var) и выяснится, что переменная-то пустая!
    И уже можешь пойти на форум не с вопросом «у меня вот код на 100 строк, где ошибка?», а «я написал функцию, но почему-то, когда обращаюсь в ней к переменным, они все пустые». или «из формы не передаются переменные».
    Между этими двумя способами задания вопросов — пропасть.
    Первый не может тебе помочь никак. Ты, собственно, и сам не знаешь, что у тебя за проблема. А при втором ты уже знаешь проблему, и, если сам не справился с ее решением, то можешь задать на форуме конкретный вопрос.

    Еще очень поможет избежать ошибок в программе выставление error_reporting в E_ALL с самого начала работы скрипта.
    Если при отлове критических ошибок сообщения о потенциальных ошибках могут нам помешать увидеть главную, то при разработке нам желательно видеть все — и потенциальные в том числе. Скажем, при E_ALL, при обращении к несуществующей переменной, PHP выдаст предупреждение. То есть, тебе не придется самому выводить переменную, чтобы выяснить, что ты не присвоил ей никакого значения — РНР тебя сам предупредит.

    Пример отладки.
    Из html формы передаются чекбоксы с именами c_1, c_1, c_3. c_10
    В скрипте мы пытаемся в цикле вывести
    for ( $i = 1 , $i 11 , $i ++) <
    echo $_POST [ ‘с_$i’ ];
    >
    скрипт ничего не выводит.
    Начинаем отлаживать.
    Сначала смотрим в исходный код html страницы. соответствует ли она стандартам?
    Допустим, соответствует. Значит, проблема не в форме.
    Далее, проверяем в скрипте — а есть ли такая переменная, к которой мы обращаемся — массив $_POST?
    пишем

    echo ‘

    ‘ ;
    var_dump ( $_POST );

    Убеждаемся в том, что массив есть и все элементы на месте. Значит, проблема не в передаче.
    Значит, мы как-то неправильно обращаемся к массиву.
    обращаемся мы к нему так: $_POST[‘с_$i’]
    Надо проверить — а во что превращается ‘с_$i’?
    делаем echo ‘с_$i’; и видим. совсем не то, что ожидали увидеть.
    И вот теперь уже идем либо читать документацию про строки в пхп (что предпочтительнее), либо — на форум, с вопросом «почему у меня переменная не заместилась своим значением». Каковой вопрос будет гораздо лучше звучать, чем «у меня форма не работает».
    Понятно?

    Следует понимать, что здесь приведён пример, Нереальный. Показан алгоритм действий.
    В реальности, при error_reporting(E_ALL); PHP сразу же показал бы, что индекс массива у вас неправильный.

    Самое важное — знать, что ты хочешь получить.
    Примерно половина вопросов на форумах вызвана тем, что человек делает что-то. НЕ ЗНАЯ, что именно!
    Самый гениальный вопрос всех времён и народов: «у меня база съела все переводы строк из текстарии».
    Человек просто не дал себе труд посмотреть, как будет выглядеть HTML, который он хочет получить, и решил, что переводы строк съела база.
    И так во всём.
    Непризнанный гений строит сложный SQL запрос, а когда его спрашивают, как запрос должен выглядеть — он только хлопает глазами. ВСЕГДА СНАЧАЛА составьте запрос руками и выполните в консоли или phpmyadmin! А после того, как получили нужный запрос и отладили — милости просим, составляйте его на пхп.
    Работа с удалённым хостом через сокет по протоколу HTTP — то же самое! Сначала научитесь выполнять все команды руками, посмотрите ответы сервера глазами, а потом моделируйте этот диалог в пхп.
    Работа с яваскриптом по тому же методу описана в факе «на танке»

    Запомните — на пхп вы работаете только со СТРОКАМИ! HTML страница, которую вы создаёте скриптом — это для пхп всего лишь набор строк! Ему без разницы, что в этом наборе — теги img, script или frame. Пхп за вас не сделает переводы строк, не нарисует яваскрипт. Если вы не знаете яваскрипта — то не пытайтесь создавать программу на нём с помощью PHP.
    Открывая соединение с удалённым хостом, вы посылаете строку в сокет, вы получаете строку из сокета. Пхп ничего не понимает в этих строках и за вас диалог вести не будет! Это ВЫ должны чётко понимать, что вы хотите послать в сокет, и что получить! Поэтому возьмите программу telnet, соединитесь с нужным хостом и пробуйте сначала САМИ сделать то, что хотите заставить сделать пхп.
    Если у вас не работает скрипт с сокетами — бегом в телнет смотреть, что происходит!
    SQL запрос — это СТРОКА. Вы должны себе чётко представлять, какой запрос получится в результате вашего хитроумного пхп-кода! Сервер БД не понимает конструкций intval, date, mktime и так далее! Это всё пхп-код. Результатом которого будет являться строка корректного SQL запроса. прежде, чем писать пхп код, вы должны ЧЁТКО СЕБЕ ПРЕДСТАВЛЯТЬ, КАК ДОЛЖЕН ВЫГЛЯДЕТЬ SQL ЗАПРОС В РЕЗУЛЬТАТЕ!
    Если у вас не выполняется SQL запрос 0 выводите его на экран и смотрите — что нагородили своим скриптом!

    Заключение.
    Отладка — главное занятие программиста.
    Отладка — единственный и самый мощный способ найти ошибку в программе.
    Отладка состоит из двух основных компонентов:
    1. Максимально упрощать пример. Если у вас не работает программа, которая рисует форму,получает данные, записывает данные формы в базу и выводит их снова, то разбейте программу на составляющие и выполняйте по очереди.
    Если у вас не работает сложная подпрограмма определения работоспособности кук — напишите сначала тест в две строчки чтобы убедиться, что вы хотя бы можете выставлять и читать куку.
    2. Вывод отладочной информации.
    Проверяйте значение КАЖДОЙ переменной! Каждого значения, возвращаемого функцией!
    Не работает локейшен? Выведите его на экран и скопируйте в браузер!
    В файл записывается пустая строка? проверяйте составляющие этой строки на каждом этапе ее создания и выводите на экран!
    Убедились, что на экран выводится? Тренируйтесь писать в файл, на тестовой строке! Забитой прямо в скрипт! Уменьшайте количество неизвестных!
    И всегда смотрите не то, что показывает браузер, а ИСХОДНЫЙ HTML код!

    Надеюсь, что я смог хотя бы немного объяснить принципы этого занятия.
    Удачной отладки.

    Типичные ошибки PHP программиста

    Ошибки, подобно этой, часто встречаются на сайтах:
    Warning: Use of undefined constant LOCAL_SERVER — assumed ‘LOCAL_SERVER’ in /web/includes/page-definitions.php on line 13

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

    Функция error_reporting позволяет нам решить, какие ошибки мы хотим видеть.
    В принципе, достаточно просто выключить показ всех ошибок (error_reporting(0)), но этого делать не стоит, потому что мы как раз и хотим видеть ошибки в php коде, вредящие безопасности.

    Константа всех ошибок php — E_ALL.
    В PHP 5 появилась константа E_STRICT, показывающая строгие замечания по поводу кода.
    Разумеется, их желательно видеть, но они не входят в E_ALL, потому будем использовать числовое значение error_reporting(8191), которое вбирает всё, вплоть до новых ошибок PHP 6.

    Примечание: error_reporting(E_ALL | E_STRICT) не подходит, ибо тогда PHP 4 будет ругаться, не зная, что такое E_STRICT. С численным же значением никаких проблем не будет.

    Добавляем проверку на DEBUG — константу, выставленную в конфиге, и, с помощью set_error_handler, будем отлавливать ошибки в уже запущенном сервисе. Кстати, свой репортер ошибок должен возвращать true, иначе PHP выбросит стандартную ошибку.

    PHP для начинающих. Обработка ошибок // PHP

    Не совершает ошибок только тот, кто ничего не делает, и мы тому пример – трудимся не покладая рук над созданием рабочих мест для тестировщиков :)

    О да, в этой статье я поведу свой рассказа об ошибках в PHP, и том как их обуздать.

    Ошибки

    Разновидности в семействе ошибок

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

    Чтобы ни одна ошибка не ушла незамеченной потребуется включить отслеживание всех ошибок с помощью функции error_reporting(), а с помощью директивы display_errors включить их отображение:

    Фатальные ошибки

    Самый грозный вид ошибок – фатальные, они могут возникнуть как при компиляции, так и при работе парсера или PHP-скрипта, выполнение скрипта при этом прерывается.

    E_PARSE
    Это ошибка появляется, когда вы допускаете грубую ошибку синтаксиса и интерпретатор PHP не понимает, что вы от него хотите, например если не закрыли фигурную или круглую скобочку:

    Или написали на непонятном языке:

    Лишние скобочки тоже встречаются, и не важно круглые либо фигурные:

    Отмечу один важный момент – код файла, в котором вы допустили parse error не будет выполнен, следовательно, если вы попытаетесь включить отображение ошибок в том же файле, где возникла ошибка парсера то это не сработает:

    E_ERROR
    Это ошибка появляется, когда PHP понял что вы хотите, но сделать сие не получилось ввиду ряда причин, так же прерывает выполнение скрипта, при этом код до появления ошибки сработает:

    Не был найден подключаемый файл:

    Было брошено исключение (что это за зверь, расскажу немного погодя), но не было обработано:

    При попытке вызвать несуществующий метод класса:

    Отсутствия свободной памяти (больше, чем прописано в директиве memory_limit) или ещё чего-нить подобного:

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

    Рекурсивный вызов функции. В данном примере он закончился на 256-ой итерации, ибо так прописано в настройках xdebug:

    Не фатальные

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

    E_WARNING
    Частенько встречается, когда подключаешь файл с использованием include , а его не оказывается на сервере или ошиблись указывая путь к файлу:


    Бывает, если используешь неправильный тип аргументов при вызове функций:

    Их очень много, и перечислять все не имеет смысла…

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

    Когда обращаются к неопределенной переменной:

    Когда обращаются к несуществующему элементу массива:

    Когда обращаются к несуществующей константе:

    Когда не конвертируют типы данных:

    Для избежания подобных ошибок – будьте внимательней, и если вам IDE подсказывает о чём-то – не игнорируйте её:

    E_STRICT
    Это ошибки, которые научат вас писать код правильно, чтобы не было стыдно, тем более IDE вам эти ошибки сразу показывают. Вот например, если вызвали не статический метод как статику, то код будет работать, но это как-то неправильно, и возможно появление серьёзных ошибок, если в дальнейшем метод класса будет изменён, и появится обращение к $this :

    E_DEPRECATED
    Так PHP будет ругаться, если вы используете устаревшие функции (т.е. те, что помечены как deprecated, и в следующем мажорном релизе их не будет):

    В моём редакторе подобные функции будут зачёркнуты:

    Обрабатываемые

    Этот вид, которые разводит сам разработчик кода, я их уже давно не встречал, не рекомендую их вам заводить:

    • E_USER_ERROR – критическая ошибка
    • E_USER_WARNING – не критическая ошибка
    • E_USER_NOTICE – сообщения которые не являются ошибками

    Отдельно стоит отметить E_USER_DEPRECATED – этот вид всё ещё используется очень часто для того, чтобы напомнить программисту, что метод или функция устарели и пора переписать код без использования оной. Для создания этой и подобных ошибок используется функция trigger_error():

    Теперь, когда вы познакомились с большинством видов и типов ошибок, пора озвучить небольшое пояснение по работе директивы display_errors :

    • если display_errors = on , то в случае ошибки браузер получит html c текстом ошибки и кодом 200
    • если же display_errors = off , то для фатальных ошибок код ответа будет 500 и результат не будет возвращён пользователю, для остальных ошибок – код будет работать неправильно, но никому об этом не расскажет

    Приручение

    Для работы с ошибками в PHP существует 3 функции:

    • set_error_handler() — устанавливает обработчик для ошибок, которые не обрывают работу скрипта (т.е. для не фатальных ошибок)
    • error_get_last() — получает информацию о последней ошибке
    • register_shutdown_function() — регистрирует обработчик который будет запущен при завершении работы скрипта. Данная функция не относится непосредственно к обработчикам ошибок, но зачастую используется именно для этого

    Теперь немного подробностей об обработке ошибок с использованием set_error_handler() , в качестве аргументов данная функция принимает имя функции, на которую будет возложена миссия по обработке ошибок и типы ошибок которые будут отслеживаться. Обработчиком ошибок может так же быть методом класса, или анонимной функцией, главное, чтобы он принимал следующий список аргументов:

    • $errno – первый аргумент содержит тип ошибки в виде целого числа
    • $errstr – второй аргумент содержит сообщение об ошибке
    • $errfile – необязательный третий аргумент содержит имя файла, в котором произошла ошибка
    • $errline – необязательный четвертый аргумент содержит номер строки, в которой произошла ошибка
    • $errcontext – необязательный пятый аргумент содержит массив всех переменных, существующих в области видимости, где произошла ошибка

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

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

    С обработчиком, который написан выше есть одна существенная проблема – он не ловит фатальные ошибки, и вместо сайта пользователи увидят лишь пустую страницу, либо, что ещё хуже, сообщение об ошибке. Дабы не допустить подобного сценария следует воспользоваться функцией register_shutdown_function() и с её помощью зарегистрировать функцию, которая всегда будет выполняться по окончанию работы скрипта:

    Данная функция будет срабатывать всегда!

    Но вернёмся к ошибкам, для отслеживания появления в коде ошибки воспользуемся функцией error_get_last(), с её помощью можно получить информацию о последней выявленной ошибке, а поскольку фатальные ошибки прерывают выполнение кода, то они всегда будут выполнять роль “последних”:

    Задание
    Дополнить обработчик фатальных ошибок выводом исходного кода файла где была допущена ошибка, а так же добавьте подсветку синтаксиса выводимого кода.

    О прожорливости

    Проведём простой тест, и выясним – сколько драгоценных ресурсов кушает самая тривиальная ошибка:

    В результате запуска данного скрипта у меня получился вот такой результат:

    Теперь добавим ошибку в цикле:

    Результат ожидаемо хуже, и на порядок (даже на два порядка!):

    Вывод однозначен – ошибки в коде приводят к лишней прожорливости скриптов – так что во время разработки и тестирования приложения включайте отображение всех ошибок!

    Тестирование проводил на PHP версии 5.6, в седьмой версии результат лучше – 0.0004 секунды против 0.0050 – разница только на один порядок, но в любом случае результат стоит прикладываемых усилий по исправлению ошибок

    Где собака зарыта

    В PHP есть спец символ «@» – оператор подавления ошибок, его используют дабы не писать обработку ошибок, а положится на корректное поведение PHP в случае чего:

    При этом обработчик ошибок указанный в set_error_handler() всё равно будет вызван, а факт того, что к ошибке было применено подавление можно отследить вызвав функцию error_reporting() внутри обработчика, в этом случае она вернёт 0 .

    Если вы в такой способ подавляете ошибки, то это уменьшает нагрузку на процессор в сравнении с тем, если вы их просто скрываете (см. сравнительный тест выше), но в любом случае, подавление ошибок это зло

    Исключения

    В эру PHP4 не было исключений (exceptions), всё было намного сложнее, и разработчики боролись с ошибками как могли, это было сражение не на жизнь, а на смерть… Окунуться в эту увлекательную историю противостояния можете в статье Исключительный код. Часть 1. Стоит ли её читать сейчас? Думаю да, ведь это поможет вам понять эволюцию языка, и раскроет всю прелесть исключений

    Исключения — исключительные событие в PHP, в отличии от ошибок не просто констатируют наличие проблемы, а требуют от программиста дополнительных действий по обработке каждого конкретного случая.

    К примеру, скрипт должен сохранить какие-то данные в кеш файл, если что-то пошло не так (нет доступа на запись, нет места на диске), генерируется исключение соответствующего типа, а в обработчике исключений принимается решение – сохранить в другое место или сообщить пользователю о проблеме.


    Исключение – это объект который наследуется от класса Exception , содержит текст ошибки, статус, а также может содержать ссылку на другое исключение которое стало первопричиной данного. Модель исключений в PHP схожа с используемыми в других языках программирования. Исключение можно инициировать (как говорят, “бросить”) при помощи оператора throw , и можно перехватить (“поймать”) оператором catch . Код генерирующий исключение, должен быть окружен блоком try , для того чтобы можно было перехватить исключение. Каждый блок try должен иметь как минимум один соответствующий ему блок catch или finally :

    В каких случаях стоит применять исключения:

    • если в рамках одного метода/функции происходит несколько операций которые могут завершиться неудачей
    • если используемый вами фреймверк или библиотека декларируют их использование

    Для иллюстрации первого сценария возьмём уже озвученный пример функции для записи данных в файл – помешать нам может очень много факторов, а для того, чтобы сообщить выше стоящему коду в чем именно была проблема необходимо создать и выбросить исключение:

    Соответственно ловить данные исключения будем примерно так:

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

    Теперь, если использовать эти исключения то можно получить следующий код:

    Важно помнить, что Exception — это прежде всего исключительное событие, иными словами исключение из правил. Не нужно использовать их для обработки очевидных ошибок, к примеру, для валидации введённых пользователем данных (хотя тут не всё так однозначно). При этом обработчик исключений должен быть написан в том месте, где он будет способен его обработать. К примеру, обработчик для исключений вызванных недоступностью файла для записи должен быть в методе, который отвечает за выбор файла или методе его вызывающем, для того что бы он имел возможность выбрать другой файл или другую директорию.

    Так, а что будет если не поймать исключение? Вы получите “Fatal Error: Uncaught exception …”. Неприятно.
    Чтобы избежать подобной ситуации следует использовать функцию set_exception_handler() и установить обработчик для исключений, которые брошены вне блока try-catch и не были обработаны. После вызова такого обработчика выполнение скрипта будет остановлено:

    Ещё расскажу про конструкцию с использованием блока finally – этот блок будет выполнен вне зависимости от того, было выброшено исключение или нет:

    Для понимания того, что это нам даёт приведу следующий пример использования блока finally :

    Т.е. запомните – блок finally будет выполнен даже в том случае, если вы в блоке catch пробрасываете исключение выше (собственно именно так он и задумывался).

    Для вводной статьи информации в самый раз, кто жаждет ещё подробностей, то вы их найдёте в статье Исключительный код ;)

    Задание
    Написать свой обработчик исключений, с выводом текста файла где произошла ошибка, и всё это с подсветкой синтаксиса, так же не забудьте вывести trace в читаемом виде. Для ориентира – посмотрите как это круто выглядит у whoops.

    PHP7 – всё не так, как было раньше

    Так, вот вы сейчас всю информацию выше усвоили и теперь я буду грузить вас нововведениями в PHP7, т.е. я буду рассказывать о том, с чем вы столкнётесь через год работы PHP разработчиком. Ранее я вам рассказывал и показывал на примерах какой костыль нужно соорудить, чтобы отлавливать критические ошибки, так вот – в PHP7 это решили исправить, но как обычно завязались на обратную совместимость кода, и получили хоть и универсальное решение, но оно далеко от идеала. А теперь по пунктам об изменениях:

    1. при возникновении фатальных ошибок типа E_ERROR или фатальных ошибок с возможностью обработки E_RECOVERABLE_ERROR PHP выбрасывает исключение
    2. эти исключения не наследуют класс Exception (помните я говорил об обратной совместимости, это всё ради неё)
    3. эти исключения наследуют класс Error
    4. оба класса Exception и Error реализуют интерфейс Throwable
    5. вы не можете реализовать интерфейс Throwable в своём коде

    Интерфейс Throwable практически полностью повторяет нам Exception :

    Сложно? Теперь на примерах, возьмём те, что были выше и слегка модернизируем:

    В результате ошибку поймаем и выведем:

    Как видите – поймали исключение ParseError, которое является наследником исключения Error , который реализует интерфейс Throwable , в доме который построил Джек. Ещё есть другие, но не буду мучать – для наглядности приведу иерархию исключений:

    TypeError – для ошибок, когда тип аргументов функции не совпадает с передаваемым типом:

    ArithmeticError – могут возникнуть при математических операциях, к примеру когда результат вычисления превышает лимит выделенный для целого числа:

    AssertionError – редкий зверь, появляется когда условие заданное в assert() не выполняется:

    При настройках production-серверов, директивы zend.assertions и assert.exception отключают, и это правильно

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

    При написании данного раздела были использованы материалы из статьи Throwable Exceptions and Errors in PHP 7

    Отладка

    Иногда для отладки кода нужно отследить что происходило с переменной или объектом на определённом этапе, для этих целей есть функция debug_backtrace() и debug_print_backtrace() которые вернут историю вызовов функций/методов в обратном порядке:

    В результате выполнения функции debug_print_backtrace() будет выведен список вызовов приведших нас к данной точке:

    Проверить код на наличие синтаксических ошибок можно с помощью функции php_check_syntax() или же команды php -l [путь к файлу] , но я не встречал использования оных.

    Assert

    Отдельно хочу рассказать о таком экзотическом звере как assert() в PHP, собственно это кусочек контрактной методологии программирования, и дальше я расскажу вам как я никогда его не использовал :)

    Первый случай – это когда вам надо написать TODO прямо в коде, да так, чтобы точно не забыть реализовать заданный функционал:

    В результате выполнения данного кода получим E_WARNING :

    PHP7 можно переключить в режим exception, и вместо ошибки будет всегда появляться исключение AssertionError :

    В результате ожидаемо получаем не пойманный AssertionError . При необходимости, можно выбрасывать произвольное исключение:

    Но я бы рекомендовал использовать метки @TODO , современные IDE отлично с ними работают, и вам не нужно будет прикладывать дополнительные усилия и ресурсы для работы с ними

    Второй вариант использования – это создание некоего подобия TDD, но помните – это лишь подобие. Хотя, если сильно постараться, то можно получить забавный результат, который поможет в тестировании вашего кода:

    Третий теоретический вариант – это непосредственно контрактное программирование – когда вы описали правила использования своей библиотеки, но хотите точно убедится, что вас поняли правильно, и в случае чего сразу указать разработчику на ошибку (я вот даже не уверен, что правильно его понимаю, но пример кода вполне рабочий):

    Никогда не используйте assert() для проверки входных параметров, ведь фактически assert() интерпретирует строковую переменную (ведёт себя как eval() ), а это чревато PHP-инъекцией. И да, это правильное поведение, т.к. просто отключив assert’ы всё что передаётся внутрь будет проигнорировано, а если делать как в примере выше, то код будет выполняться, а внутрь отключенного assert’a будет передан булевый результат выполнения

    Если у вас есть живой опыт использования assert() – поделитесь со мной, буду благодарен. И да, вот вам ещё занимательно чтива по этой теме – PHP Assertions, с таким же вопросом в конце :)

    В заключение

    Я за вас напишу выводы из данной статьи:

    • Ошибкам бой – их не должно быть в вашем коде
    • Используйте исключения – работу с ними нужно правильно организовать и будет счастье
    • Assert – узнали о них, и хорошо
    Илон Маск рекомендует:  Mysql и perl взаимовыгодное сотрудничество
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL