Повреждение “для” цикла с помощью “повреждения”, которое рассматривают вредным? [дубликат]

Обязательный:

Дело в том, что вы не должны избегать этого исключительно из-за плохой практики (или велоцирапторов), а рассматривайте это в индивидуальном порядке.

Все дело в ясности. Как вы сказали, вам никогда не придется его использовать, но в некоторых случаях это способствует удобочитаемости. Это полезно, когда цикл обычно завершается нормально, но в редких случаях вам приходится выходить из строя. Циклы, которые обычно (или всегда) ломаются, больше похожи на запах кода (но все же могут быть уместными).

Я думаю, что ваш друг ненормальный. break совершенно приемлем, отлично читается и прекрасно обслуживается. Период.

Я предлагаю этот алгоритм, если вы рассматриваете возможность использования данной техники.

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

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

Нет проблем не только с break , но и нормально использовать goto , когда break недостаточно . Также не бойтесь многократных возвратов.

Все вышеперечисленное применимо только в том случае, если это упрощает понимание кода *.

* И если ваш PHB это позволяет ...

Не только нет проблем с использованием break , я бы сказал, что любой, кто говорит, что это «считается вредным», совершенно неправ.

break - это языковая функция, используемая для прерывания цикла - вы можете использовать goto , но тогда вы навлечете (соответствующий) гнев комикса XKCD ниже. Вы можете использовать флаг в условии, но это затрудняет читаемость. break - это не только самый простой, но и самый простой способ многократно выйти из цикла. Используйте его по назначению.

Изменить: Чтобы получить более широкую картину: когда вы пишете код, руководящим принципом «следует ли мне использовать языковую функцию X или Y» должно быть «каким образом можно получить более элегантный код» ? Элегантность в коде - это в значительной степени искусство, но я бы назвал это прекрасным балансом между удобочитаемостью и алгоритмической (читай: не микрооптимизациями) эффективностью. Читаемость будет определяться длиной, сложностью кода и т. Д. Однострочное boost :: bind может быть труднее для чтения и понимания, чем трехстрочный цикл.

Если языковая функция может помочь вам написать код, который легче понять при выполнении работы, то используйте ее. Это применимо к break , goto , исключениям C ++ и т. Д. Не следуйте слепо за «X is (зло | считается вредным)» - применяйте здравый смысл и логику каждый раз.

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

На самом деле, в некоторых случаях я бы рекомендовал это. Например, если вы использовали линейный поиск, в любом случае (кроме самого худшего), перерыв улучшил бы вашу скорость. Я думаю, что выход из цикла, когда вы найдете свою иглу, будет вполне приемлемым, и это будет более читабельно, чем возиться с переменной цикла (которая может использоваться не только для цикла, в зависимости от вашей программы ) или заключить тело цикла в блок if . (И другой вариант, if , который содержит continue , сочетает худшее из двух миров: логику цикла обертывания в блоке if и плохой стиль кодирования ругают такие люди, как ваши друзья, которым не нравится перерыв .)

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

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

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