Лучшая практика при проверке условий, для вызова функции

Какова наилучшая практика?Лучшая практика при проверке условий, для вызова функции

function A() { 

    if (someClassValue > 0) { 
     B(); 
    } 

} 

function B() { 

    ...do smth, you expect (someClassValue > 0)... 
}

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

или

function A() { 

    B(); 

} 

function B() { 

    if (someClassValue > 0) { 
     return; 
    } 

    ...do smth... 
}

это может выглядеть missleading с точки зрения тела а

или

function A() { 

    if (someClassValue > 0) { 
     B(); 
    } 

} 

function B() { 

    if (someClassValue > 0) { 
     return; 
    } 

    ...do smth... 
}

это ненужно двойной проверки

Что правильный подход? должна ли функция проверить выполняемое условие или должна ли функция, вызывающая эту функцию, проверить условия для вызова B

источник

2011-12-28 Peter Lapisu

Нет неправильного или правильного пути. Это всегда является компромиссом между эффективностью и защитой вашего кода. –

Правило:Всегда проверять параметры во всех публично открытых функциях.

СООТНОШЕНИЕ: Нет необходимости проверять параметры в любых не публично открытых функциях. Это, как правило, имеет незначительное преимущество в производительности, но оно также позволяет вашему коду быть чистым и более легким для чтения, особенно если вы придерживаетесь других хороших шаблонов проектирования и предоставляете функции, ориентированные на общественность, для сворачивания частных функций для выполнения фактической работы.

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

Что касается вашего вопроса выше (который меня игнорируют), то действительно не имеет значения, какой стиль вы выбираете, до тех пор, пока вы будете следовать приведенным выше правилам. Как правило, в случае вопросов с тегами coding-style, самое главное - выбрать стиль и придерживаться его -consistency - настоящий победитель в долгосрочной перспективе.

источник

2011-12-28 16:50:32

Хорошо сказал. +1 –

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

@Peter, что вы подразумеваете под _ «вызывающей публикой?» _ Кто является вызывающим - больше вашего собственного кода или чужого кода который потребляет ваши функции? –

# 2. Вы не можете предположить, что каждая вызывающая функция будет правильно проверять.

источник

2011-12-28 16:47:34 ethrbunny

Вот почему у вас есть тестирование черного ящика. Вы хотите, чтобы функции могли обрабатывать ошибочные вызовы. – ethrbunny

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

Есть B часть этого публичного API? Если это так, я бы сказал, что вам вообще не следует доверять ввод неизвестного кода (например, потребителя вашего API), поэтому выполните проверку в B.

источник

2011-12-28 16:50:28

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

Дополнительная информация необходима, если вы хотите получить более точный ответ.

источник

2011-12-28 16:51:50

Лучшая практика при проверке условий, для вызова функции

ответ

Смежные вопросы