Які плюси та мінуси мови використовують пробіли та {} 'для позначення обсягу? [зачинено]

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

Будь-яка мова, яка має пробіли як лексеми, повинна померти.

опубліковано пізніше за тією ж відповіддю:

Я сортував анти-пробіли-маркери, поки я фактично не спробував це. Можливо, це допомогло моєму особистому розташуванню білого простору в значній мірі відповідати тому, що використовують усі в python-land. Можливо, це я дещо мінімалізм, але якщо ти все-таки будеш відступати, чому б це турбуватись {} s?

Я бачу кілька чітких аргументів для кожної сторони:

за допомогою пробілів:

• допомагає зменшити непослідовне відступ у коді
• очищає екран, замінюючи видимі лексеми пробілами, щоб служити тій самій цілі

за допомогою лексем:

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

Чи є моменти, які я пропустив? Якому ви віддаєте перевагу? Будь-які слова мудрості після того, як довго працювали з тим чи іншим?

PS. Я ненавиджу це, коли мови не використовують один і той же маркер для кожної структури управління. VB насправді дратує своїми End Ifта End Whileтвердженнями, більшість інших мов просто використовують {} для всього. Але, можливо, це тема для іншого питання ...

Я думаю, що багато з нас, програмістів (включаючи і мене), мають тенденцію "логізувати" кожне рішення. Це добре, але не на кожне питання є логічна відповідь. Наприклад, я сумніваюся, що кухарі ставлять запитання про chefoverflow (якщо така річ існує), запитуючи плюси і мінуси яблучного пирога проти вишневого пирога. Це питання, яке вам більше подобається.

Зважаючи на це, я думаю, що найпростіша відповідь - сказати "Деяким людям підтяжки, деякі люблять пробіли" і залишити це при цьому.

Загрожуючи, що це здасться шаленим фанбоєм, я думаю, що всі, хто стверджує, що пробіл "допомагає зменшити непослідовне відступ у коді", ніколи не використовував Visual Studio. З однією командою (я думаю, що ярлик за замовчуванням - Ctrl + K, D), усі відступи миттєво узгоджуються¹. Крім того, при вставці коду відступ миттєво виправляється без необхідності робити що-небудь, і те саме стосується написання нового коду або під час загортання чогось у ifякийсь інший блок (переформатування відбувається, коли }вводиться). Крім того, натискання клавіші Enter після завершеного оператора завжди ставить курсор на правильний рівень відступу для наступного висловлювання, навіть якщо попереднє твердження було відрезано далі черезifабо подібне, що робить його дуже важким випадково подумати, що твердження все ще є під, ifколи це не так.

Справа, яку я намагаюся зробити, не в тому, що Visual Studio чудова. Я намагаюся зробити те, що IDE може автоматизувати фіксацію відступів (та інші проблеми форматування), але лише в тому випадку, якщо значення програми не залежить від її форматування. Це дає програмісту більшу можливість зосередитись на власне завдання програмування. Синтаксис на зразок Python є контрпродуктивним: неможливо написати IDE, який може "виправити" відступ коду Python, оскільки саме відступ визначає частину семантики.

¹ _{(Я знаю, що існує особливий випадок, який VS відмовляється переформатувати, а саме масиви літералів, які охоплюють декілька рядків, але це поруч із пунктом.)}

Особисто мені здається, що мені потрібен порожній рядок, введений жетоном на його власний рядок, щоб я зрозумів, що код знаходиться в іншій області.

Я ненавиджу, коли в python люди ходять:

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
}

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

Pro: У світі Python, наскільки я знаю, немає святих воєн з відступом / фігурними дужками. Прийняття цього рішення від імені розробників, ймовірно, врятувало певний біль.

Con: Анонімні функції обмежені одним рядком. Звучить нормально, але я часто можу писати багаторядкові lambdaсхеми в схемі (здебільшого, щоб подати в mapабо applyв одному місці, тому окремо декларувати не було б сенсу).

{} додає надмірності. Занадто багато надмірності - це погано, занадто мало - погано. І ручне введення в нього погано, особливо. якщо його важко використовувати.

Тож у часи поганого / без IDE стиль білого простору може бути дещо кращим. Але з потужним IDE, брекети краще.

Проблема, яку я виявив із мовою пробілів, полягала в умовних виразах на кількох сторінках. Додавання рядка в середині другої сторінки та виходу на один пробіл посеред усіх безладів може кардинально змінити логіку вашого коду. І навіть якщо чийсь код "правильний", спроба його прочитати робить жахливу гру відгадування. Для кого "якщо" це "ще"? Я можу рахувати дужки набагато простіше, ніж можу порахувати невидимі порожні символи. І техніка розміщення на цьому веб-сайті продовжує розбивати їх в єдиний простір.

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

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

Справа в тому, що брекет-мови також можуть накласти правильний відступ у компіляторі, і ми мали б найкраще з обох світів. Побачити? НЕ проти взагалі.

Pythoneers стверджують, що дужки марні, коли відступ є частиною синтаксису, але це не так, дужки покращують читабельність. Я спробував програмувати Python, і це дуже цікава мова для мене, але чи намагалися ви мати if-elifланцюги більше 2 або 3 рівнів відступу? вони вже не виглядають такими охайними.

PS: Я писав дужки, але більш загальним чином я маю на увазі маркери з роздільниками. Відкриття дужки можна вважати зайвим, але мова може так виглядати (насправді я впевнений, що такі мови точно такі, але я їх не знаю добре):

if condition:
    statement
    other_statement()
end

PS2: 2019, через 4 роки після цієї відповіді. Я навчився Python і повністю звик до його смислового відступу і зовсім не важко читати. Особливо за допомогою сучасних ІДЕ, які малюють вертикальні смуги для ідентифікації блоків відступу.