А вот и наглядный пример, того как нельзя использовать @
  

BuShaRt, а почему же нельзя?

GZep, 
Все ошибки и нотейсы должны выводиться пре откладке 
и
полностью скрываться на уровне конфигурации PHP пре использование движка.

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

Если копать глубже, то конструкция

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


т.е. по суте ты предлагаешь вернуться к старым, непродуманным методам кодирования, когда есть методы более современные и поддержанные видущими программистами...

Если хочется так, то не пойму в чем проблема:


Или я что-то упустил? Никак не могу понять в чем проблема написания данной функции?

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

а лично я вижу в этом подходе только преимущества в сравнении с "раздельным хранением":
1) ортодоксальный алгоритм загрузки и перекрытия дефолтных значений(не "сколько переменных - столько и вызовов функций", а один foreach)
2) данные, которые могут прийти из форм, собраны в одной переменной - массиве: так что внешние связи отделены от внутренних. Удобно и компактно для изменения.
3) (скорее, камень в огород "раздельнохранимости") очень часто надо инициировать переменные, хранящие значения из форм, дефолтными значениями на случай отсутсвия данных.
При раздельном хранении будет дополнительно ещё куча строк с присвоением. В случае массива - одна строка инициализации массива 

никакой ошибки isset не генерирует!

и тут тоже никакой ошибки не генерируется!

не в этом случае. Тут просто проверяем существование переменной и все.

if (@...) - абсолютно не старый способ и его как раз ведущие программисты и используют. А ваш isset будет пропускать все значения кроме null, поэтому его надо использывать в связке с empty => слишком громоздкая конструкция - ниодин "ведущий" программист так писАть не будет.

GZep, 
я понял в чем проблема, ты просто не знаешь значение оператора @.
Это вовсе не сокращенная форма isset, а сокрытие ошибок...

Удостоверься



mishaSL, 
А что в данном случае означает оператор & ?

Передача аргумента в функцию по ссылке.

mishaSL, 
Что то знакомое, но вспомнить не могу, можно  чуть поподробние?

Уважаемые, конструкция: $a= isset($_GET["a"])?$_GET["a"]:false;
неправильная, хотя бы потому, что если вы дальше будете использовать конструкцию: if(!$a) {если нету} то эта конструкция будет выполняться также и если а установлена и равна 0. ;)

Для упрощения работы с формамы я использую (если количество переменных динамическое значение) масивы переменных.
то есть 

Очень удобно потом проверять ;)
если устанолвена A, то проверяем их количество, если не совпало - форма пришла левая.
Если совпало, проверили на SQL баги, и удобно делать проверки с помощью циклов.

надеюсь вам помог )

Добавлено через 3 минуты и 5 секунд
BuShaRt, это значит что передается не значение переменной, а ее ссылка.
то есть:

Выше есть подобный вариант, но там переменная передается не по ссылки, а клонируется, поэтому возникают ошибки.

Добавлено через 2 минуты и 16 секунд
ЗЫ: Оказалось парня успел поправить уже mishaSL )

Это сообщение отредактировал(а) CyClon - 4.5.2007, 14:32

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

Вот пример:

Т.е. мы можем далее смело использовать переменные $action и $page


*Смело, если конечно не передаем эти данные в уязвимые места кода... но это другая история...


Всем
Спасибо, что открыли мне оператор &.

Добавлено через 6 минут и 24 секунды
Выдержка из стать: Осторожно, данные!
Автор: Кузьма Феськов

Первое правило безопасности
Первое, что вы должны научиться делать, это принимать данные из правильных источников.
Основные источники данных в PHP – это суперглобальные массивы, в частности $_GET и
$_POST. Приучайте себя брать данные именно из этих массивов. Также не лишним будет
отметить, и тот факт, что параметр php.ini register_globbals должен быть off.
Немного поясню последнее замечание о register_globbals. Ни раз мною замечалось – до сих пор
многие программисты не понимаю почему этот параметр важно устанавливать в значение off.
Многим кажется удобным, что переменные, переданные в скрипт методом POST или GET сразу
появляются в пространстве скрипта и готовы к использованию. Однако, это удобство крайне
обманчиво. Во-первых, если вы используете в своем скрипте какую-то переменную и заранее не
позаботились об инициализации ее значения, то, дописав в URL ее название, я легко могу
переопределить ее значение на нужное мне, в результате ваш скрипт этого даже не заметит. Во-
вторых, вы никогда не будете знать точно, каким именно образом вам передана та или иная
переменная. Есть и другие менее значимые факторы. Исходя из всех этих замечаний, легко
понять, что опасность подобного подхода весьма велика и он прямо ставит под угрозу написанные
вами скрипты.
PHP Inside'18 >> Идеи >> Осторожно, данные!
После небольшого отступления, давайте перейдем к практике. Итак, к нам поступила (или не
поступила) переменная методом GET:

О переменной мы заранее знаем, что она придет методом GET, будет содержать целое число.
Первым делом, мы присваиваем значение локальной переменной. Естественно, многие сделали
это следующим способом:

Однако, что произойдет в том случае, если переменная не пришла (возможно кто-то пытался
испытать ваш скрипт на прочность и стер ее из URL)? Правильно – вы получите сообщение об
ошибке (NOTICE мы договорились считать ошибкой). Чтобы этого не произошло, необходимо
изменить наш код следующим образом:

Для простоты кода и удобства, я применил в данном случае так называемую короткую нотацию
оператора if. В обычном виде скрипт выглядел бы так:

Но, согласитесь, эта запись слишком громоздка.
Давайте вернемся к нашему коду. Мы с вами использовали команду isset, которая проверяет
наличие переменной или индекса в массиве, и возвращает false если такого элемента нет, и true,
если он есть. Что позволяет нам избежать обращения к несуществующему элементу. Поскольку
мы заранее знаем, что эта переменная может содержать только целые числа, то, не анализируя ее
содержимое, мы приводим его к целому числу. В данном случае мы применили короткую команду
(int), которая эквивалентна intval(). Даже если вам передадут в этой переменной вместо числа
строку, данная команда приведет ее к числу 0, что является целым числом и вполне удовлетворяет
нашему требованию.
Это, безусловно, очень простой пример, но он способен показать все хитросплетения и повороты,
которые подстерегают нас на пути написания скрипта.
Итак, первое правило: Всегда берите значения там, откуда они должны придти в скрипт.
Всегда проверяйте переменные и индексы массивов на существование перед их
использованием. Всегда инициализируйте значения переменных перед их использованием.

BuShaRt, 

Вы не правы. Я прекрасно знаю, что делает @ и & и так далее... Прочитайте труд Дмитри Котерова "PHP5 В подлиннике" и убедитесь сами, что в подобных случаях использование @ куда более грамотно чем isset/empty. С г-ном Д. Котеровым не поспоришь...  

А не проще-ли, для сокрытия ошибок от конечного пользователя просто отключить их отображение в интерпретаторе? )