Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+25
bool Channel::applyPreprocessorSettings()
{
if (captureDeviceID_.empty() || !isSafeToChangeSettingsNow())
CHANNEL_LOG("deferring applyPreprocessorSettings()");
needApplyPreprocessorSettings_ = true;
return false;
// ... (куча кода)
return true;
}Никогда - слышите, НИКОГДА! - не пишите на C++ одновременно с питоном.
Запостил: 
Kirinyale,
09 Апреля 2013
Follow us!
Переходи на sql.
А он там есть?
На чуть посвежевшую голову всерьёз призадумался: почему в данном конкретном случае компилятор не выдал варнинг "unreachable code"? Придётся завтра проверять, что там лиды за warning level поставили...
В питоне тоже? :)
Я-то тоже к такой паранойе привык было, но постоянные переключения начинают мешать. Уже и для ифов скобки забываю иногда, но это хотя бы не компилируется.
Почему?
Проблем изза того, что return всегда в последней строке никогда не было.
проблема не в ретурне.
А IDE "помогла" ему, и не отменила лишние отступы в неподобающих местах, поэтому он не заметил ошибку.
Чего ради мне в этом случае писать else после ветки, заканчивающейся return? Для красоты? Для того, чтобы добавить лишний отступ перед всем, что идёт дальше?
Мой пример - лишь иллюстрация того, что правило "одна точка выхода из функции" в общем случае никак не спасает от ошибки, на которую попался автор.
А, ну так к его посту и надо было ответ писать, чтоб не путаться.
Определяться мне пока не с чем. Я только понять пытаюсь, на чём основана эта Ваша странная идея, что return нужно ставить только в конце функции, а всё остальное - от лукавого.
Это же целое идиологическое направление, взявшее начало от Дейкстры.
У функциональщиков также принято возвращать значение последнего выражения, но досрочный ретурн сымитировать таки можно через монаду Cont.
- когда я читаю код, то расстояние до левого края мне сообщает о том, что этот код выполняется всегда, безусловно. Это простое правило, которому просто следовать интуитивно (сокращает время потраченное на чтение).
- отлаживать функцию в которой нет преждевременных окончаний - проще, т.как можно просто на предпоследней строчке вызвать отладчик, не вдаваясь в подробности / не обвешивая фунцию вызовами отладчика по периметру.
- в языках, где существуют всякие вариации синтаксиса, такого типа, как в примере выше это помогает избежать подобные ситуации, т.как любой код, который бы должен был выполнятся по условию будет механически помещен за гарда этого условия (либо if, либо else).
- написание покрытия тестами становится немного проще (но не существенно).
Если ради этого мне нужно пожертвовать одной "ступенькой" - мне это видится вполне приемлимой платой. Наверное, это меньше понравится людям, которые пишут по 8 пробелов в "ступеньке"... но я к ним не отношусь.
Вообще, смотря для чего и в каких масштабах. По удобству работы со стандартными контейнерами, безусловно, питон убирает плюсы одной левой. Но повсеместно-принудительная "свободная" типизация и прочие прелести вроде автосоздания переменных присваиванием очень напрягают, когда 99% ошибок и опечаток, которым C++ не дал бы даже скомпилироваться, приходится ловить в рантайме, несмотря на всю PyCharm'овскую подсветку (а иногда и "благодаря" ей).
Особенно мне это нравится при работе с серверной частью: написал большой кусок кода (или порефакторил существующий), залил на сервер, запустил. Глянул в логи, нашёл трейсбек, поправил. Остановил сервер, перезалил, перезапустил. Глянул в логи, нашёл следующий трейсбек. Поправил, остановил, перезалил, перезапустил... и так пару часиков. :)
Питон здесь - пристройка к движку, на которой нужно писать практически всю логику (в том числе клиент-серверную). В рамках моей текущей задачи C++ нужен только для непосредственной работы с одним сторонним SDK.
Оба работаем руками.
Питон без юнит-тестов юзать нельзя. Вообще.