Я вважаю за краще один вихід, якщо це дійсно не ускладнює речі. Я виявив, що в деяких випадках кілька існуючих точок можуть маскувати інші більш значні проблеми дизайну:
public void DoStuff(Foo foo)
{
if (foo == null) return;
}
Побачивши цей код, я одразу попрошу:
- Чи "foo" колись недійсний?
- Якщо так, то скільки клієнтів "DoStuff" коли-небудь називають функцію з нульовим "foo"?
Залежно від відповідей на ці запитання, це може бути саме так
- перевірка є безглуздою, оскільки вона ніколи не відповідає дійсності (тобто це повинно бути твердженням)
- перевірка буває дуже рідко, і тому, можливо, буде краще змінити ці конкретні функції виклику, оскільки вони, ймовірно, повинні в будь-якому випадку вжити інших дій.
В обох вищезазначених випадках код, ймовірно, може бути перероблений із твердженням, щоб переконатися, що "foo" ніколи не буває нульовим, а відповідні абоненти змінені.
Є дві інші причини (конкретні, я думаю, для коду С ++), коли існує декілька, насправді можуть мати негативний вплив. Вони мають розмір коду та оптимізацію компілятора.
Об'єкт, який не є POD C ++ в області дії на виході з функції, матиме назву деструктора. Якщо є кілька тверджень про повернення, можливо, в обсягах існують різні об'єкти, тому список деструкторів, які потрібно викликати, буде різним. Тому компілятору необхідно генерувати код для кожного оператора return:
void foo (int i, int j) {
A a;
if (i > 0) {
B b;
return ; // Call dtor for 'b' followed by 'a'
}
if (i == j) {
C c;
B b;
return ; // Call dtor for 'b', 'c' and then 'a'
}
return 'a' // Call dtor for 'a'
}
Якщо розмір коду є проблемою - то цього, можливо, варто чогось уникати.
Інший випуск стосується "Оптимізації іменованого повернення значення" (він же Copy Elision, ISO C ++ '03 12.8 / 15). C ++ дозволяє програмі пропустити виклик конструктора копій, якщо він може:
A foo () {
A a1;
// do something
return a1;
}
void bar () {
A a2 ( foo() );
}
Просто приймаючи код таким, який є, об'єкт 'a1' будується у 'foo', і тоді його конструкція копіювання буде викликана для побудови 'a2'. Однак копія elision дозволяє компілятору сконструювати "a1" там же, що знаходиться на стеку, як "a2". Тому немає необхідності "копіювати" об'єкт, коли функція повертається.
Кілька точок виходу ускладнює роботу компілятора в спробі виявити це, і принаймні для відносно недавньої версії VC ++ оптимізація не відбулася там, де тіло функції мало кілька повернень. Докладніші відомості див. У розділі Оптимізація іменованого значення повернення у Visual C ++ 2005 .