Проверка входящих значений функции

[nigirma]

Есть функция, в самом ее начале производится проверка входящего(их) значения.

/**
 * Демонстрационная функция проверки входящих значений
 * 
 * @param  int    $size Число от 0 до 3
 */
function demoCheckParam($num = 0) {
    // ПРОВРКА $num
    
    // код функции не интересующий нас сейчас
}

Есть несколько вариантов проверок:
1)

if (($num < 0) || ($num > 3)) {
    $num = 0;
}

2)

if (($num !== 0) && ($num !== 1) && ($num !== 2) && ($num !== 3)) {
    $num = 0;
}

3)

if (!in_array($num, $access)) {
    $num = 0;
}

4)

if (!preg_match('/^([0-3])$/', $num)) {
    $num = 0;
}

Для каждого есть свои минусы:
1) Неправильно обрабатывается если введена строковая переменная. Например если $num = 'gkhuimn' то проверка будет пройдена, т.к. при сравнении $num с числом, $num будет равна нулю...
2) Ужасная нечитабельная запись. Также теряется возможность задавать в качестве параметра параметры так: '2'. А иногда бывают случаи такого объявления, например через форму на сайте.
3) В несколько раз медленней чем первый вариант и имеет такую же ошибку как первый, т.ч. отметается 100%
4) Самый работающий без ошибок вариант, но медленней чем третий в 2 раза (примерно в 8-10 раз медленней чем первый вариант).

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

 

[Вурдалак]

1) Неправильно обрабатывается если введена строковая переменная. Например если $num = 'gkhuimn' то проверка будет пройдена, т.к. при сравнении $num с числом, $num будет равна нулю...

Либо забей, либо жди type hinting'а для скаляров, либо смени PHP на другой язык.

Есть ещё вот это, кстати: http://ru2.php.net/manual/ru/book.spl-types.php

 

[Фанат]

медленней чем третий в 2 раза (примерно в 8-10 раз медленней чем первый вариант).

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

 

[Фанат]

$access = array(0,1,2,3);
$num = $access[array_search($num,$access)];

А 4 вариант пропустит 3333333. Зачем там плюс-то?

 

[nigirma]

Фанат

А 4 вариант пропустит 3333333. Зачем там плюс-то?

да плюсик по ошибке поставил. Убрал сейчас

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

Не стыдно. Микрооптимизация это.
Десять тыщ. человек (посещаемость) * 10 (кол-во открытых страниц) * 20 (в среднем функций на страницу) * 3 (проверяемых аргумента в среднем в функции) = небольшая но экономия =)

 

[флоппик]

Не стыдно. Микрооптимизация это.
Десять тыщ. человек (посещаемость) * 10 (кол-во открытых страниц) * 20 (в среднем функций на страницу) * 3 (проверяемых аргумента в среднем в функции) = небольшая но экономия =)

Вот откуда они берутся, такие наивные-то?
Добавочная стоимость железки которая покроет эти тысячи этих «микрооптимизаций» меньше зарплаты программиста за день.
Элеметарный кеш полученных значений покроет 99% «микрооптимизаций» махом и вообще ничего не будет стоить.

ДЕЛОМ ЗАНИМАЙСЯ, НЕ ФИГНЕЙ.

 

[Фанат]

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

 

[флоппик]

Да я не о экономии, а о том, что надо программировать, а не фигней страдать.

 

[флоппик]

Ну, а что до разницы — в трех примерах разный код, который, на самом деле, делает разные вещи )

 

[nigirma]

флоппик
убили мое рвение к микрооптимизации.
Убедили.

 

[флоппик]

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