php собачка перед переменной
Php собачка перед переменной
I was confused as to what the @ symbol actually does, and after a few experiments have concluded the following:
* the error handler that is set gets called regardless of what level the error reporting is set on, or whether the statement is preceeded with @
* it is up to the error handler to impart some meaning on the different error levels. You could make your custom error handler echo all errors, even if error reporting is set to NONE.
* so what does the @ operator do? It temporarily sets the error reporting level to 0 for that line. If that line triggers an error, the error handler will still be called, but it will be called with an error level of 0
Hope this helps someone
Be aware of using error control operator in statements before include() like this:
(@include( «file.php» ))
OR die( «Could not find file.php!» );
?>
This cause, that error reporting level is set to zero also for the included file. So if there are some errors in the included file, they will be not displayed.
It’s still possible to detect when the @ operator is being used in the error handler in PHP8. Calling error_reporting() will no longer return 0 as documented, but using the @ operator does still change the return value when you call error_reporting().
My PHP error settings are set to use E_ALL, and when I call error_reporting() from the error handler of a non-suppressed error, it returns E_ALL as expected.
But when an error occurs on an expression where I tried to suppress the error with the @ operator, it returns: E_ERROR | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR | E_RECOVERABLE_ERROR (or the number 4437).
I didn’t want to use 4437 in my code in case it changes with different settings or future versions of PHP, so I now use:
And, of course, if your error_reporting settings in PHP is something other than E_ALL, you’ll have to change that to whatever setting you do use.
If you’re wondering what the performance impact of using the @ operator is, consider this example. Here, the second script (using the @ operator) takes 1.75x as long to execute. almost double the time of the first script.
Error suppression should be avoided if possible as it doesn’t just suppress the error that you are trying to stop, but will also suppress errors that you didn’t predict would ever occur. This will make debugging a nightmare.
It is far better to test for the condition that you know will cause an error before preceding to run the code. This way only the error that you know about will be suppressed and not all future errors associated with that piece of code.
There may be a good reason for using outright error suppression in favor of the method I have suggested, however in the many years I’ve spent programming web apps I’ve yet to come across a situation where it was a good solution. The examples given on this manual page are certainly not situations where the error control operator should be used.
Please be aware that the behaviour of this operator changed from php5 to php7.
The following code will raise a Fatal error no matter what, and you wont be able to suppress it
Quick debugging methods :
There is no reason to NOT use something just because «it can be misused». You could as well say «unlink is evil, you can delete files with it so don’t ever use unlink».
?>
There are only 2 possible problems here: a missing variable or a missing index. If you’re sure you’re fine with both cases, you’re good to go. And again: suppressing errors is not a crime. Not knowing when it’s safe to suppress them is definitely worse.
After some time investigating as to why I was still getting errors that were supposed to be suppressed with @ I found the following.
1. If you have set your own default error handler then the error still gets sent to the error handler regardless of the @ sign.
Знак собаки @ и подавление ошибок в PHP
Последняя модификация: 16.09.2016 г
Страница загружена с адреса: http://webdesign.site3k.ru/consulting/array_walk_error.html 
Знак собаки @ и подавление ошибок в PHP
Как-то столкнулся с любопытной проблемой: при обработке массивов функцией вызванной командой array_walk, вместо того, чтобы проверять наличие массива, решил подавить сообщение ошибки, если массива нет. Как говорится, на нет и суда нет. Массив не был обязательной частью данных, он мог быть создан в результате действия предыдущего кода, а мог и не быть, в зависимости от различных условий. При наличии, массив обрабатывался, при отсутствии выдавалось сообщение об ошибке. Вот я и решил не проверять существование массива, а поставить в array_walk собаку, чтобы упростить код.
Я был сильно удивлен, когда обнаружил, что массив перестал обрабатываться.
Далее я создаю 3 тестовых массива с набором слов и для каждого из них вызываю функцию обработки командой array_walk. Но в первом случае я использую array_walk в чистом виде, а в двух следующих использую подавление сообщения об ошибке, если указанного массива не существует. При этом в одном варианте я ставлю собаку перед вызовом функции, а в другом перед именем массива. Вначале мне показалось, что это дает одинаковый результат. Для проверки я вывел содержимое массивов после обработки внутри блока
Внутри функции drink все шло по плану. PHP готов был пить и чай, и молоко, и даже пиво. По крайней мере, вывод на экран внутри функции соответствовал ожидаемому. Но на деле оказалось, что он филонит и тайком выливает виски под стол, потому как при проверке массива через print_r, слово «пить» не присоединилось, ни к пиву, ни к виски.
Почему так происходит, мне совершенно непонятно. Ведь внутри функции все выглядело великолепно независимо от положения собаки при вызове.
Далее последовала проверка подавления ошибки. Вызов обработки несуществующего массива без собаки вполне ожидаемо выдал сообщение об ошибке «аргумент должен быть массивом». Вызов обработки, предваренный собакой, ожидаемо умолчал об ошибке. А вот что будет при вызове с собакой перед массивом, заранее не было известно. То ли PHP будет нем, как рыба, потому что о массиве ему говорить запрещено, то ли начнет жаловаться, что аргумент должен быть массивом. Оказалось, жалуется. Жалуется, если массива нет. Симулирует обработку, если массив есть. То есть, помещение собаки перед массивом не только не отключает сообщение об ошибке, но и само вызывает ошибку при обработке данных.
Только помещение собаки перед вызовом функции дает желаемый результат: если массив есть, он обрабатывается, если его нет, PHP молча проходит мимо.
На последок хочу добавить, что вместо array_walk в большенстве случаев лучше использовать array_walk_recursive, который обработает не только простые массивы, но и многомерные со всеми их уровнями вложенности. Лучше использовать array_walk_recursive сразу, чем потом, в случае изменения массива, проверять, обрабатывается ли он рекурсивно.
Как устроены переменные в PHP
Вроде простой вопрос, даже не понятно что на него ответить, правда?
Мы все знаем как создать переменную, как получить значение переменной, как взять ссылку на переменную в конце концов.
Но как они работают изнутри?
Что происходит в интерпретаторе, когда вы изменяете значение переменной? Или когда удаляете ее?
Как реализованы типы переменных?
В этой статье я постараюсь раскрыть именно эти темы.
Abstract
Переменные в PHP выражены в виде неких контейнеров, которые хранят в себе тип переменной, значение, кол-во ссылающихся переменных на этот контейнер, и флаг — является ли эта переменная ссылочной.
Отступление про структуры и указатели
Если вы никогда не писали на Си, то возможно не знаете про такие вещи, как структуры и указатели, которые очень широко тут используются и без которых пожалуй было бы очень сложно представить себе хоть сколько нибудь сложную программу на Си.
Структуры очень похожи на классы, только они не могут иметь методов, только данные, указатели на данные и указатели на функции. Объявляя структуру в Си, вы определяете тип данных, и теперь при определении переменной, вы можете написать имя этой структуры на месте типа той переменной, примерно так:
Указатели — это как переменные-ссылки, только их значение — это адрес в памяти. На самом деле, это ссылки как указатели, только они ведут себя как разыменованные указатели. Лучше показать на коде:
Контейнеры
Контейнером служит структура под названием zval, она выглядит так:
В итоге, когда вы будете создавать переменную этого типа, она займет в памяти ровно столько, сколько занимает самый тяжелый элемент юниона. 
Зачем столько лишнего?
Теперь разберем — зачем тут, например, какой-то refcount?
А очень просто: когда вы присваиваете переменной значение другой переменной, то они обе ссылаются на один zval, а refcount инкрементируется. 
(оригинал с собачкой тут)
Теперь, если вы захотите изменить значение одной из этих переменных, то PHP, увидя refcount больше 1, скопирует этот zval, сделает изменения там, и ваша переменная будет указывать уже на новый zval.
Если это немного формализовать, то это будет выглядеть примерно так:
| PHP | Под капотом |
|---|
Эта техника называется copy on write и она позволяет неплохо снизить потребление памяти.
Также, refcount нужен сборщику мусора, который удаляет из памяти все zval-ы, у которых refcount = 0.
А что делать с ссылками и зачем вообще этот is_ref?
А что происходит со ссылками? Все очень просто: если вы создаете ссылку от переменной, то флаг is_ref становится равным 1, и больше вышеописанная оптимизация для этого zval-а применяться не будет. Поясню кодом:
| PHP | Под капотом |
|---|
Конечно, если вы возьмете еще одну ссылку от foo, то refcount zval-а, на который ссылается foo, увеличится на один.
Пожалуй на этом (пока?) все, в следующей части поговорим о массивах.
PS не знаю кто как воспримет эти картинки, мне показалось это будет забавно 🙂 к сожалению сканера у меня нет
PHP Code Style Conventions
В данной статье рассматривается подход к написанию и оформлению PHP кода. Нижеизложенные моменты были сформированы путем анализа существующих подходов компаний и личного опыта.
Правила именования файлов и папок
Все названия для папок и файлов должны быть осмысленными и говорящими (не требующие дополнительного разъяснения).
Папки
Если папка хранит в себе классы, которые относятся к пространству имен (namespace), то папка именуется в соответствии с названием пространства имен (namespace).
Файлы
Если файл является файлом класса, то именуется в соответствии с названием класса.
Правила именования пространств имен, классов, методов и переменных
Все названия должны быть осмысленными и говорящими (не требующие дополнительного разъяснения).
Пространства имен
Названия пространств имен должны быть в нижнем регистре и состоять из одного слова. В случае необходимости именовать пространств имен более одного слова производится дробление на составные части, являющиеся вложенными пространствами имен.
Классы
Методы
К названиям методов применяются следующие правила:
Переменные
К названиям переменных применяются следующие правила:
Название переменной должно передавать намерения программиста
Название переменной должно сообщить, почему эта переменная существует, что она делает и как используется
Название переменной не должно быть коротким
Если переменная хранит признак, то он должен быть включен в название ( unpaidProject )
Переменные и свойства объекта должны являться существительными и называться так, чтобы они правильно читались при использовании, а не при инициализации
Плохо:
Хорошо:
Запрещены отрицательные логические названия
Плохо:
Хорошо:
Правила оформления кода
В первую очередь ставится пространство имен (namespace), которое используется (если есть). Далее пишется конструкции использования классов ( use ). В случае использования нескольких
классов одного пространства имен происходит группировка с помощью конструкции <. >. Далее идет объявление класса.
Фигурные скобки ставятся на той же строке и разделяются пробелом.
Каждая переменная должна быть объявлена на новой строке.
Условия и служебные вызовы методов разделяются переносом строки, переменные и работа с ними переносами строк не разделяются.
Внутри условий и циклов дополнительный перенос на новую строку не ставится.
Содержимое класса разделяется сверху одной пустой строкой.
Перед возвращаемым значением( return ) обязательно ставится перенос строки, если метод не состоит из единственной строки.
Если условие является большим, то обязательно выделить его в одно или несколько смысловых выражений и использовать его (их) в условии.
Плохо:
Хорошо:
Комментирование кода
В общем случае комментарии запрещены (НЕ «всегда»). Любой участок кода, который необходимо выделить или прокомментировать, надо выносить в отдельный метод.
Комментарии должны быть расположены перед объявлением классов, переменных и методов и быть оформлены в соответствии с PHPDoc. Комментарий перед классом должен содержать описание бизнес-логики и отражать его назначение с приведением примеров использования.
Готовые алгоритмы, взятые из внешнего источника, должны быть помечены ссылкой на источник.
Правила написания кода
Везде, где имеет смысл, должнно быть прописано declare(strict_types=1);
Нельзя изменять переменные, которые передаются в метод на вход (исключение — если эта переменная объект).
Строки обрамляются одинарными кавычками. Двойные кавычки используются только, если:
Вместо лишней конкатенации используем подстановку переменных в двойных кавычках
Метод должен явно отличать нормальные ситуации от исключительных.
По умолчанию тексты исключений не должны показываться пользователю. Они предназначены для логирования и отладки. Текст исключения можно показать пользователю, если оно явно для этого предназначено.
В условном операторе должно проверяться исключительно boolean значение. В сравнении не boolean переменных используется строгое сравнение с приведением типа ( === ), автоматическое приведение и нестрогое сравнение не используются.
При использовании в условном выражении одновременно операторов И и ИЛИ обязательно выделять приоритет скобками.
Использование @
Доброго времени суток.
Встретился с использованием оператора @, но не знаю для чего он. Прошу, Вас, по возможности, объяснить что делает данный оператор. Или дать ссылки на статьи.
Работа с двумерными числовыми массивами. Использование указателей. Использование функций пользователя.
Помогите пожалуйста. Сделать три варианта: первый вариант – передача данных между.
Создание и использование своих @NamedQueries. Использование EntityManager
Добрый день! Создавал классы сущностей и сессий через NetBeans генераторы кода. Использование.
Использование строк.Использование структур
Задачка: Дана строка,состоящая из групп нулей и едениц. Найти и вывести на экран группы с нечетным.
Да я ни за ни против. Просто говорю, что не всегда это так.
И таких примеров есть. А посему это:
не всегда верно. Иногда можно и даже должно.
А никто и не спорит.
Вообще лошадь на 4 ногах и то спотыкается. В любом программном продукте возможны ошибки. PHP не исключение, в нем тоже не все гладко. И хорошо, что есть инструменты, позволяющие эти шероховатости безболезненно сгладить.
Нельзя все отметать вчистую.
Если вы не любите собак, значит вы просто не умеете их готовить. (с) Корейская мудрость.
Добавлено через 30 минут
kester
Кстати, раз на то пошло. Ваш код плох хотя бы тем, что ошибки уровня WARNING не останавливают скрипт. А значит он становится заложником обстоятельств. С теми же правами. А вот пожалуйста и права и прочее:
Решение
«Безболезненно», говорите? Собака делает всё настолько «гладко», что с тем же успехом можно закрыть глаза, зарыть голову в песок и притвориться, что не видел, и что меня/тебя это не касается. Вот и нет проблемы. Но проблема от этого никуда не девается.
Используя собаку, Вы прячетесь от абсолютно любых ошибок, а не только от той, которую ожидали. В большинстве случаев Вы не можете быть уверены на 100%, что в данном месте не могут возникнуть никакие другие проблемы, кроме ожидаемой. Не следует забывать тонкую разницу между сообщениями об ошибках и настоящими источниками ошибок. Много разных причин могут привести к одному ошибочному результату.
Лично я, как настоящий параноик, не пожалею полграмма ресурсов на лишние 42 проверки в пользу диагностики, чтобы предусмотреть любой разумный вариант исхода. И никакие логи нигде не забьются бесполезными сообщениями. Зато потом ни я, ни, тем более, кто-то другой не будете выдирать волосы на голове в поисках черной кошки в черной комнате. Лучше пусть программа работает правильно и чуть более качественно, насколько у меня хватит способностей, чем быстро и хрен пойми как.
Любой фрагмент кода выполняет свою задачу. Если код выполнился без ошибок, значит он всё сделал именно так, как задумал его создатель. Мне не нужен код, который радостно мне сообщает, что всё прошло успешно, когда на самом деле это не так. Пусть он лучше из кожи вылезет, засрет мне все логи и все почтовые ящики, но об ошибке я должен знать.
На моей машине первый цикл отрабатывает в среднем за 1.5 сек, второй за 12.5. Что же я такого не знаю об этом операторе?
И откуда столько сарказма: святая водичка, религиозные нормы, недоверие под покровом ночи? Мы кажемся маленькими и тупыми с высоты Ваших безмерных познаний?
Согласен с Vovan-VE: профессиональный программист обязан быть параноиком.
Хорошо, я понял. У нас разные взгляды на программирование. Я придерживаюсь принципа KISS, у вас здоровая доля паранойи. Обе точки зрения имеют права на жизнь.
Но вот с этим я не соглашусь:
Не от любых, а именно от тех, которые, как вы и сами заметили, обусловлены «кривизной архитектуры языка».
Вернемся к unlink(). Функция вполне логично возвращает true в случае успешного завершения и false в случае фиаско. Этого вполне достаточно для дебаггинга. На кой ляд она еще и генерирует WARNING? Или допустим почившая в бозе mysql_result(). C какой целью она генерирует ошибку, если успешный запрос не вернул ни одной строчки? Причем тут вообще PHP. Или к примеру file_get_contents() с удаленными файлами?
Ну какая польза от логов, в которых будет записано
если это временное помешательство сбой связи? Ну никакой практической пользы.
Нет, я понимаю, когда это специальный лог (журнал), но он не имеет отношения к интерпретатору ошибок.
Добавлено через 23 минуты
philin,
Вот вы не правы, как и многие, кто пытается познать истину подобными тестами.
Вы пытаетесь сравнить время выполнения кода с оператором @ и без него. Разумеется, любой оператор требует времени и памяти. Однако вы забываете, что если не ставить собаку, придется делать другие проверки. И вот теперь напишите подобный тест на тот код, который привел в пример kester. Ну я помогу:
Добавлено через 2 минуты
Ненене, секундочку. Я не предлагал использовать собаку при обращениях к переменной. Ну уж коль на то пошло, ладно. Что показывает ваш тест. Что код с собакой работает в три раза медленее чем с isset()? Ну да, так и есть. Только одно но. В каком страшном сне может привидится 10! миллионов. обращений? А если уменьщить количество итераций в вашем тесте до хоть как то вписывающиеся в рамки разумного 1000, то абсолютная разница (не в процентах) не выйдет за рамки погрешности. Да и представить себе скрипт, в котором будет 1000 проверок на существование переменной я как то очень слабо могу.
О каком реальном (не теоретическом) выигрыше в скорости мы сейчас рассуждаем? В 1-2 пикосекунды на весь скрипт?
Ну а вернувшись к нашим баранам, все же напомню. Что я не призывал cтавить собаку везде и всюду. Тем паче в обращениях к переменной. Но в тех местах, где она действительно полезна, там и по скорости вопросов не возникает. Тест вы видели.
Не соглашусь с Вами также в том, что не важна причина, по которой файл не смог удалиться (мне показалось, Вы именно так это преподносите), по которой соединение порвалось и т.п. Если соединение рвется 1 раз в неделю в пятницу вечером, то я, видя такую статистику, еще соглашусь, что это в определенной степени допустимо. Но если, например, в той же статистике я увижу, что соединение врется несколько раз у сутки, то это уже проблема, и её надо как-то решать, если это возможно.
А без инфы об ошибках я вообще ничего никогда не узнаю. Получится т.н. синдром УМВР.
С причинами неудаления файла та же история. Возможные варианты причин уже писали выше.
Если ошибка (любая где бы то ни было) возникла не по моей вине, а по сторонним причинам, то и не мне брать на себя ответственность скрывать факт этой ошибки. Например, если не я [процесс, вызвавший unlink()] создал ситуацию, из-за которой удаление не прошло, то и не мне принимать решение, что с этим дальше делать (а, действительно, админ забыл раздать права, я-то [процесс, вызвавший unlink()] здесь прием? ваши проблемы, вы [люди] с этим сами и разбирайтесь).
Антипример того, что я хочу выразить, хоть и надуман и маразматичен, но главное смысл: