Почему goto плох
Где бы мне ни приходилось работать, везде в какой-то момент возникает дискуссия на тему использования или неиспользования операторов break, continue и, конечно же, goto.
О goto я читал в книгах, по-моему даже МакКоннел "Совершенный код", или что-то вроде.
В руководствах по кодированию (code style, code guide) и в книгах довод один: запутанность кода.
Однако при правильном разбиении кода на методы и нормальной архитектуре, по-моему, break и continue приводит только к большей понятности кода.
И вот, читая интереснейший цикл статей "Что каждый программист должен знать о памяти" я нарвался на доступное объяснение чем плох любой переход (JUMP) с точки зрения производительности (ссыль http://rus-linux.net/lib.php?name=/MyLDP/hard/memory/memory-6-3.html):
"Код имеет то преимущество, что между переходами он линеен. В такие периоды процессор может эффективно делать предварительную загрузку памяти. Переходы нарушают эту идеальную картину из-за того что
- цель перехода может быть определена не статически;
- даже если она определена статически, загрузка памяти может занять длительное время, если эта цель отсутствует во всех кэшах.
Эти проблемы создают задержки при выполнении кода с возможным существенным снижением производительности."
Update for myself after 6 years :)
ОтветитьУдалитьThe book "Clean Architecture" by Robert Martin says: goto prevents modules to being decomposed recursively into smaller units, thereby preventing use of divide-and-conquer approach necessary for reasonable proofs.