Почему 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):

"Код имеет то преимущество, что между переходами он линеен. В такие периоды процессор может эффективно делать предварительную загрузку памяти. Переходы нарушают эту идеальную картину из-за того что
- цель перехода может быть определена не статически;
- даже если она определена статически, загрузка памяти может занять длительное время, если эта цель отсутствует во всех кэшах.
Эти проблемы создают задержки при выполнении кода с возможным существенным снижением производительности."

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

Комментарии

  1. 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.

    ОтветитьУдалить

Отправить комментарий

Популярные

Кастомизируем ASP.NET Identity 2.0

Делаем себе бесплатный VPN на Amazon EC2

Выбираем все плюсы из трех парадигм Entity Framework