Микрооптимизация: использование typecast в качестве средства проверки

Question

Я проводил несколько сравнительных экспериментов по микрооптимизации и столкнулся с идеей тестирования приведения типов к функциям, которые проверяют определенный тип данных.В частности (int) против is_numeric ().Моя теоретическая точка зрения заключается в том, что если бы я уже удостоверился, что моя переменная действительно целочисленная, мне не нужно было бы ее проверять.

$a = (int) $_POST['a'];

В сравнении:

$v = $_POST['a']; if (is_numeric($v)){ $a = $v; }

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

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

Answer 1

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

Answer 2

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

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

Если «a» будет идентификатором строки в таблице MySQL, то, если они предоставляют какие-то странные значения, самое худшее, что может случиться, это то, что они увидят другую строку или вообще не увидят ее. Однако, если есть строки, которые не всем разрешено просматривать, должна быть какая-то процедура аутентификации, которая должна активировать и предотвратить доступ к строке.

Answer 3

Это неплохая идея, но не по тем причинам, о которых вы думаете.Это гарантирует, что то, что вы получаете из формы, всегда находится в ожидаемом вами формате данных.Это означает (для ints, float и bools в любом случае, строки - другое дело), ​​что нет способа осуществить атаку SQL-инъекцией через поля, защищенные таким образом.Это не означает наверняка, что данные будут действительны (отрицательные значения, в которых допустимы только положительные значения и т.

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