переменные не нужно проверять на isset(empty)

[samokspv]

$a = (string)@$_POST['param']; //если объявлять так переменные то не нужно проверять на isset(empty) + чуток поменьше кода

Назревает вопрос: так можно делать или предпочтительней с проверкой на существование?
Услышал комменты пару человек, они и я придерживаемся ответа что это костыль и так делать не гуд, хотелось бы узнать кто-то юзает такое из присутствующих на практике?

 

[Andkorol]

"Собака" в коде – что ж тут хорошего...?

 

[Василий М.]

http://phpfaq.ru/debug
@ вообще не использовать, она не для этого создана, что бы ты глушил явные ошибки.

вообще, с подходом "чуток поменьше кода" не надо пр-ем заниматься.

 

[С.]

samokspv, есть метода програмирования на РНР без isset() и empty(), Но во-первых, на это надо идти осознанно, представляя себе побочные эффекты. Во-вторых, это делается с помощью error_reporting (E_ALL ^ E_NOTICE); а не как не собакой.

 

[DIG]

Я иногда даже вместо $a++ пишу $a + 1, а использовать такие "конструкции" вообще считаю за гранью добра и зла. Через неделю\месяц\год сам будешь сидеть и думать что же здесь зашифровано. А уж если кто другой откроет код... Но это моё личное мнение.

 

[cDLEON]

Интересно откуда пошли все эти объяснения вроде "потом будет не понятно, что здесь зашифровано". По-моему, достаточно читаемая конструкция.
Другой вопрос, что такой подход не учитывает некоторых внешних факторов. Т.е., если ваш код будет использоваться в какой то другой среде. Например там, где есть собственный обработчик ошибок:

function exceptions_error_handler($severity, $message, $filename, $lineno) {
	throw new Exception($message);
}

set_error_handler('exceptions_error_handler');


$var = @$_POST['var'];

Ваша сабака не поможет.

 

[eax]

Можно написать функцию:

function get(array $arr, $key, $def = false) {
    return isset($arr[$key]) ? $arr[$key] : $def;
}

$login = get($_POST, 'login');

 

[С.]

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

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

 

[Фанат]

Вообще, нужно различать переменные.
Есть переменные со значением, есть переменные-флаги
есть обязательные переменные и есть опциональные.

К ним ко всем нужен разный подход.
Очень часто говнокод типа isset() или get($_POST) оказывается ничуть не лучше собаки.

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

Цель нотиса, с которым нубы так любят бороться собакой или иссетом - предупредить программиста об ошибке.
К примеру, из формы не пришло какое-то поле, ожидаемое скриптом. В этом случае иссет нам не нужен. А точнее - тупой однопроходный иссет.
Если переменная обязательная, то её либо вовсе не проверять (и тогда еррор хендлер выкинет 503) - либо после иссета сделать else, которое обработает отсутствие обязательной переменной более дружественно. Тупо заменять её на пустую строку - идиотизм.

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

 

[cDLEON]

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

А модели, я так понимаю, вы считаете, что нельзя использовать в другой среде ? Например фреймворк более новой версии. И да, работа с POST|GET|REQUEST, я считаю, должна осуществляться в контроллере.

 

[С.]

А модели, я так понимаю, вы считаете, что нельзя использовать в другой среде? Например фреймворк более новой версии

Тут только два варианта: с нотисами/без нотисов или с проверкой/без проверки. Нет и не может быть между ними промежуточных версий.

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

 

[cDLEON]

Тут только два варианта: с нотисами/без нотисов или с проверкой/без проверки. Нет и не может быть между ними промежуточных версий.

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

Это был просто пример. Не нужно бросаться в крайности. Я всерьёз верю (и пытаюсь этим пользоваться), что свои творения я могу использовать (и использую) в других проектах. Это называется "реюзабельность кода". И для того, что бы код можно легко было перенести, самым главным я для себя выделил практику избавления от влияний внешних факторов. Другими словами - обычное "избавление от зависимостей". Notice с собакой тоже своеобразная зависимость.

 

[С.]

самым главным я для себя выделил практику избавления от влияний внешних факторов. Другими словами - обычное "избавление от зависимостей". Notice с собакой тоже своеобразная зависимость.

Ну да, это позиция. У меня другая. Я не приемлю в бизнес логике конструкций типа:

if ( isset($variable) && !empty($variable) && !is_null($variable) )

вместо по-человечески читаемого:

if ( $variable )

И я говорю не про разовые использования, а когда все пестрит подобными строками. Поэтому системный код пишем в стиле 3GL, бизнес логику -- в 4GL.

Проблем при переносимости нет, поскольку первым делом мы обеспечиваем себе нужную среду (Апач,Мускл,РНР и т.п.), а потом работаем. В этом смысле гораздо больше проблем может возникнуть при смене версии РНР. Гипотетические случаи, когда де огромные куски 4GL кода надо вставить в 3GL проект. Или вдруг на середине пути мы решели перескочить с 4GL на 3GL я не рассматруваю по очевидным причинам.

 

[Absinthe]

@ вообще не использовать

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

 

[Фанат]

Absinthe, во-первых, ты передёргиваешь. Там речь шла о параллельном выполнении unlink (всякий говнокэш на файлах), а не об unlink вообще. А это две большие разницы.
Во-вторых, правильная практика всё равно будет не давить ошибку, а обрабатывать.
Потому что ошибки могут быть разные. А не только "нечего удалять, файл уже кто-то почикал".
Главная проблема нубопрограммистов с собаками заключается в том, что они думают, будто ошибка бывает только одна.

 

[cDLEON]

Ну да, это позиция. У меня другая. Я не приемлю в бизнес логике конструкций типа:

if ( isset($variable) && !empty($variable) && !is_null($variable) )

вместо по-человечески читаемого:

if ( $variable )

И я говорю не про разовые использования, а когда все пестрит подобными строками. Поэтому системный код пишем в стиле 3GL, бизнес логику -- в 4GL.

Проблем при переносимости нет, поскольку первым делом мы обеспечиваем себе нужную среду (Апач,Мускл,РНР и т.п.), а потом работаем. В этом смысле гораздо больше проблем может возникнуть при смене версии РНР. Гипотетические случаи, когда де огромные куски 4GL кода надо вставить в 3GL проект. Или вдруг на середине пути мы решели перескочить с 4GL на 3GL я не рассматруваю по очевидным причинам.

Ну, во-первых, ваш пример можно сократить до empty($variable).
Во-вторых - я не совсем понял, что именно вы подразумеваете под "бизнес логикой" ? Код в модели? В контроллере ? Или весь код в целом ? Если в целом, то я совсем не понимаю как вы боретесь с нотайсами )

 

[Absinthe]

всякий говнокэш на файлах

Не стоит забывать о шаредхостингах и движках.

Во-вторых, правильная практика всё равно будет не давить ошибку, а обрабатывать.

В данном случае отсутствие файла - не ошибка, а следствие говнопроектирования функции unlink.

 

[Фанат]

Не стоит забывать о шаредхостингах и движках.

Вот о них ты и должен был упоминать. Сам, а не после подсказки с моей стороны.

следствие говнопроектирования функции unlink.

Ну конечно. Тебя забыли спросить, как сделать правильно.

 

[cDLEON]

отсутствие файла - не ошибка

а типизированное исключение.

 

[korpus]

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

if ( $variable )

.

Что это такое?