Каковы плюсы и минусы языка, использующего пробелы и символы {} для обозначения области видимости? [закрыто]


17

Кажется, существует конфликт по поводу того, лучше ли использовать пробел или токены, такие как скобки, для обозначения области видимости. Я видел множество похвал Python для решения проблемы несовместимости отступов, но многие не согласны:

Любой язык, имеющий пробелы в качестве токенов, должен умереть.

позже опубликовал тот же ответ:

Я был вроде против пробелов, как токены, пока я действительно не попробовал это. Вероятно, помогло то, что мой личный макет пустого пространства в значительной степени соответствует тому, что используют все в python-land. Возможно, это то, что я немного минималистичен, но если вы все равно собираетесь делать отступы, зачем беспокоиться о {} s?

Я вижу некоторые четкие аргументы для каждой стороны:

используя пробелы:

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

используя токены:

  • намного проще вырезать и вставлять код на разные уровни (не нужно исправлять отступы)
  • более последовательный Некоторые текстовые редакторы по-разному отображают пробелы.
  • более популярный в настоящее время.

Есть ли какие-то моменты, которые я пропустил? Какой ты предпочитаешь? Какие-нибудь слова мудрости после долгой работы с одним или другим?


PS. Я ненавижу, когда языки не используют один и тот же токен для каждой структуры управления. VB действительно раздражает своими заявлениями End Ifи End Whileутверждениями, большинство других языков просто используют {} для всего. Но, возможно, это тема для другого вопроса ...


2
Я бы не сказал, что «гораздо проще вырезать и вставлять». Это только немного легче.
Кугель

1
Пока вы держите блоки кода небольшими и организованными, токены действительно не должны иметь значения ... кстати, вам нравится тег 'holy-war', лол
Скотт,

«Некоторые текстовые редакторы по-разному отображают пробелы.»: ?? «более популярный в настоящее время»: популярность часто не связана с качеством идеи.
Джорджио

Мне нравится синтаксис пробелов, и я любил кодировать в CoffeeScript и Haskell (да, я знаю, это сложно). Я кодировал кучу в JavaScript и C, и я просто не могу вернуться к}. Тем не менее, лучше всего использовать s-выражения на Лиспе, когда они заменяются на
div div

Я думаю, что становится труднее обнаружить ошибки, если вам приходится полагаться только на пробелы. Например: stackoverflow.com/questions/21205836/… Единственная разница между кодом ОП и ответом - это дополнительный пробел. Наличие} для определения, какой код находится внутри цикла for, а какой нет, намного понятнее.
AncientElevator9

Ответы:


15

Я думаю, что многие из нас, программистов (включая меня), склонны «логизировать» каждое решение. Это хорошо, но не на каждый вопрос есть логичный ответ. Например, я сомневаюсь, что повара отправляют вопросы о chefoverflow (если такая вещь существует), спрашивая плюсы и минусы яблочного пирога против вишневого пирога. Это вопрос, который тебе нравится больше.

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


6
Между прочим: cooking.stackexchange.com
Джон Пурди,

Кроме того, кое-что, что является профессионалом для некоторых, могло быть обманом для других.
Ларри Коулман

Отличный момент. Лично я думаю, что они работают вместе, и, пока чистая сторона чиста, я не буду жаловаться (сильно).
Майкл К

8
Я не согласен с вашей аналогией. Есть довольно объективные причины полагать, что синтаксис, зависящий от пробелов, снижает производительность труда программиста даже у программистов, которые его любят. Это все равно что говорить, что людям просто не нравится вкус цианида - все просто «логизируют», когда говорят, что он ядовит. Нет. Неважно, как сильно ты это любишь, это все равно тебя убьет.
Тимви

4
PS Слово, которое вы на самом деле ищете, рационализировать . Кроме того, все склонны к рационализации, а не только программисты.
Тимви

11

Я думаю, что рискуя походить на настоящего фаната, каждый, кто утверждает, что пробел «помогает уменьшить противоречивые отступы в коде», никогда не использовал Visual Studio. С помощью одной команды (я думаю, что ярлык по умолчанию - Ctrl + K, D), все отступы мгновенно согласуются ». Кроме того, при вставке кода отступы мгновенно исправляются, вообще ничего не делая, и то же самое верно при написании нового кода или при переносе чего-либо в какой- ifлибо или какой-либо другой блок (переформатирование происходит по мере }ввода). Кроме того, нажатие Enter после завершенного оператора всегда помещает курсор на правильный уровень отступа для следующего оператора, даже если предыдущий оператор был смещен дальше из-заifили что-то подобное, что делает очень сложным случайное представление о том, что утверждение все еще находится в состоянии, ifкогда его нет.

Суть, которую я пытаюсь подчеркнуть, не в том, что Visual Studio великолепен. Я пытаюсь подчеркнуть, что IDE может автоматизировать исправление отступов (и другие вопросы форматирования), но только если смысл программы не зависит от ее форматирования. Это дает программисту больше возможностей сосредоточиться на актуальной задаче программирования. Синтаксис, подобный Python, является контрпродуктивным: невозможно написать IDE, которая может «исправить» отступ кода Python, потому что сам отступ определяет некоторую семантику.


¹ (Я знаю, что есть особый случай, когда VS отказывается переформатировать, а именно литералы массива, которые занимают несколько строк, но это не относится к делу.)


8
Отступы Python не нуждаются в исправлении, потому что они не ломаются (без замечаний!). Невозможно написать Purify (программу, которая помогает обнаруживать утечки памяти) для C #, это не означает, что управление памятью в C ++ лучше.
2010 года

2
@Dean: Почему так много людей думают, что им нужен Resharper для всего? То, что вы описываете, уже в Visual Studio без Resharper.
Тимви

2
@dbkk: Ваш отступ нарушается, как только вы добавляете ifстроку в любом месте. Затем вы должны приступить к исправлению отступа вручную.
Тимви

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

2
@ Кевин: Правильно, у меня нет, и, честно говоря, я бы не хотел. Я бы настаивал на том, чтобы исправить все это за один раз, что вызывает только один нечитаемый разност, который затрагивает только незначительные пробелы и исправляет все будущие разности. Все остальное будет контрпродуктивно и вредно для проекта.
Тимви

3

Лично я нахожу, что мне нужна пустая строка с наличием токена на собственной строке, чтобы заставить мой разум понять, что код находится в другой области видимости.

Я ненавижу, когда в питоне люди идут:

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

в то время как на жетоне я ненавижу, когда люди копируют и вставляют, а не очищают отступы ,

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

или не используйте отдельную строку для токена .

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

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


3

Pro: Насколько я знаю, в мире Python нет священных войн с отступами / фигурными скобками. Принятие этого решения от имени разработчиков, вероятно, спасло некоторую боль.

Против: Анонимные функции ограничены одной строкой. Звучит нормально, но я часто пишу многострочные lambdas в Scheme (в основном для подачи в mapили applyв одном месте, поэтому не имеет смысла объявлять отдельно).



Многострочные выражения поддерживаются в Python - просто поставьте \ в конце строки.
ДБКК

8
Честно говоря, отсутствие многострочных лямбд является ограничением Python, а не пробелов в целом. В моем языке с пробелами, если вы вводите лямбду, а за ним следует блок с отступом, блок используется как тело лямбды.
Обратите внимание на себя - придумайте имя

@ Примечание - Хорошо, да, честно. Python - это единственный язык с пробелами, с которым у меня есть опыт работы. @dbkk, значит, вы говорите, lambda n: a = n \\na.sort() \\na[0:3] что не вернете синтаксическую ошибку? Трюк `\` позволяет вам распределить вашу однострочную лямбду по нескольким строкам, но вы все равно не получите более одной фактической строки.
Инамати

Haskell, CoffeeScript использует пробелы, но не имеет однострочного ограничения лямбды.
aoeu256

3

{} добавляет избыточность. Слишком много избыточности плохо, слишком мало плохо. И вводить вручную это плохо, особенно если его трудно использовать.

Так что во времена плохой / нет IDE, стиль пробелов может быть немного лучше. Но с мощной IDE брекеты лучше.


1
Я думаю, что вы делаете хороший вывод о избыточности. Некоторое время я размышлял над парсером-восстановлением для компиляторов (после очень интересных попыток Кланга выпустить Fix-Its для кода), и здесь действительно помогает то, что существует избыточность. Поэтому я думаю, что никакая избыточность, хотя она великолепна в идеальном мире, на самом деле вредна для программирования в реальном мире. Когда обычно избыточные источники информации не согласны, то может быть, что была допущена опечатка / ошибка; без избыточности эта потенциальная ошибка остается незамеченной! Это, как говорится, я предпочитаю без скобок;)
Матье М.

«Шум» - это слово, которое Эрик Мейер использовал в своих видео на Haskell.
user16764

Что если вы удалите блок и забудете удалить} или удалите {по ошибке, когда делаете обратное? Избыточность идет против СУХОГО ИМО.
aoeu256

2

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

IMHO "{{{{{" is more reliable than "     ".

9
Если вы используете многостраничные условные выражения, у вас есть другие проблемы. Просто не делай этого. Фактически, даже с фигурными скобками, код становится нечитаемым беспорядком. На самом деле это еще одно преимущество отступа от пробелов: оно мешает вам писать такой ужасный код.
Конрад Рудольф

1
Серьезно, условно несколько страниц ?
Уинстон Эверт

2

Я не думаю, что это действительно против .
Pythoneers часто критикуют программистов скобок, как если бы они легко нарушали отступы, потому что они могут.
На самом деле, я всегда использовал 100% -ное согласование отступов еще до того, как узнал о Python и его области видимости отступов.

Дело в том, что языки скобок также могут навязывать корректные отступы в компиляторе, и мы получим лучшее из обоих миров. Видеть? нет против вообще.

Питонеры утверждают, что фигурные скобки бесполезны, когда отступы являются частью синтаксиса, но это не так, фигурные скобки улучшают читабельность. Я пробовал программировать на Python, и это очень интересный язык для меня, но пробовали ли вы иметь if-elifцепочки с более чем 2 или 3 уровнями отступов? они больше не выглядят такими аккуратными.

PS: я написал фигурные скобки, но в более общем смысле я имею в виду токены-разделители. Открывающая фигурная скобка может рассматриваться как избыточная, но язык может выглядеть следующим образом (на самом деле я уверен, что есть такие языки, но я их плохо знаю):

if condition:
    statement
    other_statement()
end

PS2: 2019, 4 года после этого ответа. Я выучил Python и полностью привык к его семантическому отступу, и мне совсем не трудно его читать. Особенно с помощью современных IDE, которые рисуют вертикальные полосы, чтобы помочь в идентификации блоков отступа.


Мне нравится этот синтаксис, потому что это хороший компромисс и избегает скобок. Но это стоит дорого для однострочных операторов, где, например, в C мы можем полностью убрать скобки :(
Jo So

вместо вложенных, если ... elif, вы можете попробовать использовать словари и / или продолжить, вернуть, вложенные функции ...
aoeu256

@ aoeu256 совершенно не суть вопроса, и мой ответ тоже.
Петруза
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.