«Если это, то то, иначе то, а не это». Объяснение причины использования в конкретном месте для конкретной цели цикла while или цикла for. Это условности, помогающие людям избегать типичных ошибок при разработке любого ПО. При этом все такие соглашения и разъяснения не имеют никакого отношения к тому, что на самом деле происходит внутри компьютера. Они предназначены только для того, чтобы люди перестали делать типичные ошибки. Те ошибки, которые делаются всеми, постоянно и упорно.

До меня особенно долго доходило, что программисты обязательно, с некоторой периодичностью, делают ошибки. Я в прошлом году много говорил о том, что мы познакомились со статическим анализом и прогнали через него весь наш код, в результате получив сотни и тысячи выявленных проблем. И это очень круто — ведь теперь можно поднять историю, сказать «Смотри, вот тут я допустил ошибку» и показать всем место, где была допущена ошибка. Все посмотрят и для себя отметят: «О, как оно может быть! Хм, постараюсь такого не допускать». Это хорошо, но проблема-то не в следствии, а в причине. Если синтаксис позволяет что-то реализовать некорректно, то это «что-то» будет некорректно реализовано. Именно поэтому, кроме ввода статического анализа я бы хотел сильнее ограничить выразительность языковых средств и тем самым оградить программистов от совершения ошибок.

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

Мы знаем, что люди приходят и уходят. Мы знаем, что новые для проекта люди смотрят на код и не понимают его предназначения и соглашений о стиле написания. И мы знаем, что наверняка есть способы сделать это всё как лучше, так и ещё хуже — но эти способы крайне трудно формализовать.

Будучи программистом, восторгался множеством возможностей языков и сред. Ставши преподавателем, понял, что язык должен обеспечивать "правильные" способы программирования. А среда должна "бить по рукам" при малейшем отступлении от правил. Никакие увещевания и разговоры, как делать правильно, не помогают. "Что с человеком ни делай - он упорно ползет на кладбище"(с) Жванецкий.
Поэтому управление обучение должно быть институциональным, то есть принудительным. И только по мере обучения "вожжи" можно отпускать.