Когда проверять параметры функции / метода?

Question

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

Например (синтаксис C # -ish):

public void FunctionA(object param)
{
    DoA(param);
    DoB(param);
    DoC(param);
    // etc.
}

private void DoA(object param)
{
    DoD(param);
}

private void DoD(object param)
{
    // Error if param == null
    param.DoX();
}

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

Так, когда лучше всего проверить, является ли мой param-Object нулевым?

При проверке в функции A:

Pro: - Нет никаких накладных расходов за счет использования других методов, которые, наконец, ничего не сделают, потому что объект равен нулю.

Con: -Мой синтаксически замечательный FunctionA испачкан уродливым кодом проверки.

При проверке только при использовании param-объекта:

Pro: -Мой синтаксически замечательный FunctionA радостно читает:)

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

Answer 1

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

Answer 2

Если вы не думаете, что значение, вероятно, будет нулевым в подавляющем большинстве случаев, я бы поставил проверку в DoD (). Если вы поместите его в FunctionA (), вам придется повторить проверочный код позже, когда вы решите, что FunctionB () также должна использовать DoD (). Для меня лишние накладные расходы не стоят того, чтобы повторяться.

Answer 3

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

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

Answer 4

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

Возможно, вы захотите проверить Бертран Мейерс Дизайн по контракту мантра.

Answer 5

Ответственность за передачу допустимого параметра лежит на вызывающем абоненте. В этом случае:

if(param != null)
{
  FunctionA(param);
}

Answer 6

Всегда проверяйте все :) Исходя из глубоких недр библиотек кодирования для встроенных систем, я бы использовал этот метод:

public void FunctionA(object param)
{
    assert(param != null && param.canDoX());
    DoA(param);
    DoB(param);
    DoC(param);
    // etc.
}

private void DoA(object param)
{
    assert(param != null && param.canDoX());
    DoD(param);
}

private void DoD(object param)
{
    assert(param != null && param.canDoX());
    if ( param != null )
        param.DoX();
    else
        // Signal error, for instance by throwing a runtime exception
        // This error-handling is then verified by a unit test that 
        // uses a release build of the code.
}

Чтобы устранить это, очевидное решение состоит в том, чтобы разбить валидацию на отдельную функцию валидатора. Используя препроцессор в стиле C или просто придерживаясь утверждений, было бы тривиально исключить эту «параноидальную» проверку из сборок релиза.