Мой коллега только что посмотрел на мой код и сказал, что согласно «некоторому стандарту» возвращать значение функции из цикла for — плохая практика.
Функция выглядит примерно так:
bool CentralWidget::isBitFieldFree(const QString& define, int lsb, int msb)
{
QString defineWithoutIndex = getDefineWithoutIndex(define);
for (int i = lsb; i <= msb; i++)
{
if ((registerBitMap[defineWithoutIndex] >> i) & 1)
return false; //Returning here early...
else
registerBitMap[defineWithoutIndex] |= 1 << i;
}
return true;
}
Вопросы:
В мире нет такого стандарта, как этот C ++. Однако в более конкретной среде (например, в компании) могут применяться специальные стандарты.
С этим сказал, это не плохая практика, в общем.
а) стандарт, который запрещает это?
Нет.
б) это плохая практика?
Нет.
в) на вопрос уже дан ответ.
Кроме этого, это относится к сфере личных предпочтений, и вот мое — но это, очевидно, не часть реального ответа:
Вы хотите вернуться true
после того, как вы зациклили свою строку, так как вы можете сделать это элегантно внутри цикла? С if
заявление о том, что если это последняя итерация, верните true
в конце цикла?
Я думаю, что это добавляет больше строк кода в ваш файл без какой-либо причины и серьезно ухудшает читабельность.
Существует школа мысли, которая говорит, что функция должна иметь одну запись и одну точку выхода. Это облегчает некоторый статический анализ кода, но в C ++, скорее всего, не служит никакой другой цели.
Такое мышление в основном исходит из C, где может иметь смысл выходить из функции через одну точку, чтобы гарантировать, что ресурсы, в конечном итоге взятые функцией, будут должным образом очищены при выходе. Репликация этой очистки на нескольких выходах считается хрупкой и сложной в обслуживании — я согласен.
Однако в C ++ предпочтительным способом управления вашими ресурсами является использование RAII или использование RAII-классов, таких как общие указатели, string
а также vector
, Таким образом, объем кода, необходимый для очистки ресурсов при выходе, часто равен нулю, потому что это неявно делается в деструкторах объектов в локальной области видимости. Поэтому обычно не имеет смысла принудительно вводить один вход / один выход, если у вас нет веских причин для этого.
Могут быть разные мнения по этому поводу, и люди могут утверждать, что это создает «неинтуитивный» поток управления. Но есть нет стандарта за это.
Лично я считаю, что это лучше, чем иметь дополнительную переменную и условие для выхода из кода. Вы хотите выйти из области действия в этот момент, и вы делаете это, возвращаясь из функции. Иногда я даже помещаю код в дополнительную функцию, чтобы иметь возможность использовать функцию выхода из области из любого места с возвратом.
Это также имеет преимущество в создании меньшего количества строк кода. И меньше строк кода — меньше возможностей для введения ошибки.
В некоторых стандартах кодирования можно найти такие вещи, как «функция должна иметь только одну точку выхода». Часто это было связано с процедурами очистки, но во времена умных указателей это больше не применяется.
Итак, как говорят другие ответы и комментарии: нет, такого стандарта нет.
Кроме того, я не думаю, что это плохая практика.
Более того: я бы сказал, что вам не нужно «else», потому что если вы выйдете из цикла / функции, обработка продолжится только в случае «else». Не имеет большого значения в вашем случае, но если у вас есть несколько ifs, это может сэкономить вам много вложений.