Нормально ли проверять одни и те же данные по десять раз?

Question

[Алексей Николаев]

Доброй ночи.
При разработке, когда имеет место быть внедрение зависимости через аргументы функции или метода, я стараюсь всегда проверить переданные данные и, в случае чего, вернуть false или null. Однако порой один и тот же объект \ массив \ коллекция поочередно пробрасывается через несколько функций, и, соответственно, проверяется в каждой из них. Я в принципе понимаю, что это избыточно, но проверить данные только один раз в точке входа, а в остальном коде полагаться на то, что проверка уже была произведена, совесть не позволяет: что, если кто-то (или я) потом использует метод в обход точки входа, и схватит какой-нибудь fatal error? Очень грубый и натянутый пример того, что я имею в виду.

function a($array) {
    if(!is_array($array) OR !count($array)) return null;
    // code
}
function b($array) {
    if(!is_array($array) OR !count($array)) return null;
    // code
}
function main() {
    $array = get_array();
    // Проверили данные сразу после получения
    if(!is_array($array) OR !count($array)) return null;

    $result1 = a($array); // тут тоже проверка
    $result2 = b($array); // и тут - в принципе, можно бы и выкинуть, т.к. проверка есть выше
}

Стоит ли продолжать заморачиваться с проверкой передаваемых данных в каждой функции?
Спасибо.

Answer 1

[index0h]

Проверять данные в каждом методе - это вполне отличная практика, по сути это соблюдение интерфейса метода.
Но возвращать при этом null/false - практика хреновая, если ваш метод на вход требует int, а получил array - надо бросать исключение. Так вы будете знать, что внешний код, который использует ваш метод работает не корректно.

Для объектов настоятельно рекомендую использовать type hinting:

public function test(MyObject $object, $id)
{
    if (!is_int($id)) {
        throw new \InvalidArgumentException('Argument "id" must be int');
    } elseif ($id < 0) {
        throw new \InvalidArgumentException('Argument "id" must be positive');
    }
...

Если пишете на семерке, то и для скаляров и на вывод - тоже стоит указывать type hinting. Правда с выводом не всегда это можно делать, например возврата null, или что-то еще.

public function checkPositive(int $intData): bool

Для сокращения проверок можете мой пакет заюзать https://packagist.org/packages/ko-ko-ko/assert, он спроектирован под максимальную производительность и использование в каждом методе.

Стоит ли продолжать заморачиваться с проверкой передаваемых данных в каждой функции?

Да. За счет этого вы выигрываете в безопасности, надежности и времени поиска багов.

Comments

[Котик Антон]

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

[index0h]

Стектрейс читать придется в любом случае.
Даже если бросать как в примере с методом test, что вы узнаете из исключения? То, что метод вызван с не правильным аргументом, откуда вызвался? При каких условиях и т.д. это все равно будет содержаться в стектрейсе.

[Котик Антон]

index0h: Большая часть исключений выстреливает при разработке: поправил код - словил исключение - сразу понял в чем накосячил (в 99% случаев), не читая трейс. Исключения в проде - это конечно совсем другая песня, там без трейса никак.

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

[index0h]

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

> Если лепить проверки буквально во все методы, причем даже там, где они никогда не выстрелят
Когда работаешь в большой команде, понятия "никогда не выстрелит | вызовется | произойдет |..." становятся не содержательным бла-бла-бла, увы.
Код крупного проекта не пишется один раз, он меняется и развивается.

[Faer]

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

PS: Для написания пользовательских интерфейсов и публичных методов(API) такой метод действительно подходит и даже необходим.

[index0h]

Faer Отличная практика использовать php для систем реального времени, замечательная, к успеху идете))

В случае HL - стоит вопрос распределения нагрузки, а не экономии на спичках. Сэкономите вы без проверок пару мс, что теперь?))

[Faer]

index0h:
Зачёт)

Пару мс на запрос, который выполняется порядка той же пары мс уже решает. Если делать, в каждом методе(разумеется же?) такие проверки, то может выйти и больше. Тут главное - взяться за достаточно крупный проект. Вот в небольших - подобные проверки ничего не будут решать. Правда, там обычно и сервер то один. Я писал о системах реального времени т.к. они схожи с HL в том плане, что количество выполненных запросов/циклов за единицу времени сильно зависит от такой вот бесполезной нагрузки. Можно конечно просто распараллелить и закупить побольше серверов. Но лучше сделать всё тоже самое без необходимости закупки еще N серверов, необходимости их обслуживать и т.д..

Ну а для интерфейсов, я ранее об этом писал - тут необходимость. В том числе и на HL, и в реалтаймовых системах, да где угодно.
PS: веб - это не только php )

[index0h]

Faer ))
Автор в контексте php спрашивал.
Основное время выполнения как правило тратится на input/output, а это и БД, и кэши, и HTTP, и очереди, и всякие ELK и т.д. PHP сам по себе как правило занимает малую часть времени выполнения, большую часть он ждет. PHP это не быстрый язык, это язык быстрых решений. И что бы эти быстрые решения были еще и надежными - проверки необходимы. Чем крупнее проект - тем более. Почему я писал выше.

> Я писал о системах реального времени т.к. они схожи с HL в том плане.
Не схожи. Системы реального времени под HFT например - вообще ни капли не схожи с системами, рассчитанными на web.

HL - это высоко-нагруженные системы, чаще всего задача: справиться с большим потоком трафика. Подождет клиент на 20мс больше, или меньше - это не так важно. Обычно это дело решается за счет распределения нагрузки между множеством серверов. Для части кейсов - распределение клиентов между разными ДЦ, по ближе географически к ним. С точки зрения бизнеса, как правило, дешевле надежный продукт нежели быстрый, но менее надежный.

Системы реального времени - это вообще другая задача, тут нужно выжать максимум из железа, потому что передавать запросы, даже по udp - это очень долго. Тут вполне прижились сетевые карты с обходом ядра и разнообразные FPGA под конкретные бизнес задачи. На Wall Street даже длинна кабеля имеет цену (меньше заплатишь - длиннее кабель будет). И про php тут речи быть не может.

> веб - это не только php )
Да я и не спорю, в компилируемых языках статической типизацией куча проблем php просто не существует.

Answer 2

[Andry]

Разделите код на группы:
- контачит с опасным миром входных данных (публичный метод, которому скармливают $_POST['x'] и т.д.)
- используется только в безопасной среде (приватные методы, классы глубоких внутренностей бизнес-логики, которые по нормальному никогда не используются из "грязной" среды)

И станет ясно, где проверка нужна строгая, а где достаточно указать типизацию параметра и в остальном доверять данным, которые 100% уже проверил другой код-санитар.

И веселее было бы использовать исключения. В этом случае b($array) из вашего примера уже никто и не вызывали бы.

Answer 3

[Дмитрий]

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

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