Гвидо фон Россум
Из интервью с Гвидо Ван Россумом , которое можно увидеть в полном тексте с books.google.com (выделено мое):
Выбор отступа для группировки не был новой концепцией в Python; Я унаследовал это от ABC , но это также произошло в Occam, более старом языке. Я не знаю, получили ли авторы ABC идею от occam, или изобрели ее самостоятельно, или был ли общий предок. Конечно, я мог бы решили не следовать примеру АВС, как я делал в других областях (например, ABC используется верхний регистр для ключевых слов языка и имен процедур, идею я не копировать), но я пришел , как особенность довольно немного при использовании ABC, поскольку это, казалось, покончило с определенным типом бессмысленных дебатов, распространенных среди пользователей C в то время, о том, где разместить фигурные скобки .
Фон Россум был сильно вдохновлен ABC , и хотя ему не нужно было копировать все это, использование отступов было сохранено, потому что это могло быть полезно во избежание религиозных войн.
Мне также было хорошо известно, что читаемый код в любом случае добровольно использует отступ для обозначения группировки, и я столкнулся с тонкими ошибками в коде, когда отступ не соглашался с синтаксической группировкой с использованием фигурных скобок - программист и все рецензенты предполагали, что отступ соответствует группировке и поэтому не заметил ошибку. Опять же, долгий сеанс отладки преподал ценный урок.
Россум также засвидетельствовал ошибки из-за несоответствия между группировкой и отступом, и, очевидно, хотя полагание, что использование отступа только для структурирования кода будет более защищено от ошибок программирования 1 .
Дональд Э. Кнут и Питер Дж. Ландин
В упомянутом интервью Гвидо упоминает идею Дона Кнута об использовании отступов. Это подробно описано в « Обнаруженной цитате отступа Кнута» , которая цитирует структурированное программирование с помощью операторов goto . Кнут также ссылается на следующие 700 языков программирования Питера Джона Ландина (см. Раздел «Обсуждение»). Ландин разработал ISWIM, который выглядит как первый язык с отступом вместо блоков начала / конца. Эти документы больше о целесообразности использования отступов для структурирования программ, чем о реальных аргументах в пользу этого.
1. Я думаю, что это на самом деле аргумент в пользу наличия как группирующих конструкций, так и автоматического форматирования, чтобы выявлять и исправлять ошибки программирования, которые неизбежно произойдут. Если вы испортили свой отступ в Python, человек, который отладит ваш код, должен будет угадать, что правильно:
if (test(x)):
foo(x)
bar(x)
Должен bar
всегда быть вызван или только если тест успеха?
Группирующие конструкции добавляют уровень избыточности, который помогает вам обнаружить ошибку при автоматическом отступе кода. В C эквивалентный код может быть автоматически вставлен следующим образом:
if (test(x))
foo(x);
bar(x);
Если я собирался bar
быть на том же уровне, что foo
и авто-отступ, основанный на структуре кода, то я вижу, что есть что-то неправильное, что можно исправить, добавив фигурные скобки foo
и bar
.
В Python: мифы об отступах есть предположительно плохой пример из C:
/* Warning: bogus C code! */
if (some condition)
if (another condition)
do_something(fancy);
else
this_sucks(badluck);
Это тот же случай, что и выше, в Emacs, я выделяю весь блок / функцию, нажимаю Tab, а затем весь код переопределяется. Расхождение между человеческими отступами и структурой кода говорит мне о том, что что-то не так (это и предыдущий комментарий!).
Кроме того, промежуточный код, где отступ в C отключен, просто не проходит через главную ветку, все проверки стилей заставили бы GCC / Jenkins кричать на меня. У меня недавно была проблема, похожая на описанную выше в Python, с оператором, отступившим на один уровень отступа. Иногда у меня есть код на C, который выходит за пределы закрывающей скобки, но затем я нажимаю Tab и код «отступает»: это еще один шанс увидеть ошибку.
let x =1; y = 2; z = 3
полностью действителен, как естьdo { putStrLn $ show x; putStrLn $ show y; putStrLn $ show z; }
. Те не должны быть на одной линии.