Комментарии 196
Python кажется удобней, но с++ привычней. От того и удобней… Даже не знаю как ответить на вопрос ваш.
Не понятно, отвечать на вопрос «Какой тип вы считаете удобным?», или «Какой тип, лично для вас, удобней?»
Не понятно, отвечать на вопрос «Какой тип вы считаете удобным?», или «Какой тип, лично для вас, удобней?»
До недавнего времени все писал на Java и других С++ подобных языках. А вот месяца 3-4 назад захотелось изучить питон. С тех пор стало страшно смотреть на другие языки. Настолько в питоне все просто и красиво выглядит.
try ruby ;)
Я когда-то последовал такому совету, и страшно разочаровался: для меня руби по сравнению с питоном совсем уродлив и непонятен. Такой вот я странный, да. Так что на любителя.
мм… для меня Питон чересчур туповат показался после Руби. Наверное, не так его готовил.
Да, всё на вкус и цвет.
Да, всё на вкус и цвет.
Дело в том, что в питоне искусственно ограничивается число «сахарных» фишек, вносимых в язык, дабы не засорять синтаксис. У разработчиков есть негласные правила, ограничивающие сложность парсера. Это — главная фича языка. Грамматика его в сравнении с Руби — как, допустим, эсперанто в сравнении с произвольным языком славянской группы. Не уверен, что подобную политику можно назвать «туповатой»!
yes try it. we have cookies
Скобки дают больше свободы для форматирования кода, можно писать маленькие функции в одну строку, как пример. Но порой это приводит к страшной нечитабельности кода, во втором случае с этим меньше проблем.
Мне первый вариант больше по душе.
Мне первый вариант больше по душе.
При втором варианте тоже можно писать маленькие функции в одну строку. Если абстрагироваться от примеров конкретных языков.
Вообще говоря, в рамках обоих стилей можно писать функции длиной в строку, я могу даже пример привести. Привести?:)
А еще из-за чрезмерной свободы написания рождаются никому не нужные споры о том, с какой строки ставить открывающую скобку.
ИМХО рефакторинг языка без скобок проще в силу большей очевидности. Не надо искать/запоминать конечную/начальную скобку для удаления/добавления блока. Ну для добавления часто редактор умеет брать выделение в скобки, а вот удалять часто не умеет, хотя я сталкивался с проблемой кода редактор умел наращивать табуляцию у блока, а сокращать не умел, но это реже и скорее вопрос инструмента. В любом случае искать пары скобок в PHP мне было сильно сложнее (т.к. их же можно ставить в одной строке) чем теперь нужные блоки в Python.
К тому же выравнивание блоков кода отступами принуждает писать читабельный код
НЛО прилетело и опубликовало эту надпись здесь
Не спорю, но тем не менее, на Си можно написать нечто в этом роде (откопал в сети)
#include <stdio.h>
main(t,_,a)char *a;
{ return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)):1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?main(2,_+1,"%s %d %d\n"):
...
НЛО прилетело и опубликовало эту надпись здесь
Думаю имелось в виду то, что в языках с блоками выделяемыми скобками никто не запрещает написать блок или несколько в строку и поставить скобки в нужных местах. Это скомпилируется и будет работать, но читать и понимать этот код сильно сложнее, в отличие от того же Python где такое не скомпилируется и код в большинстве случаев читается лучше в силу таких ограничений синтаксиса.
IMHO для таких опросов и статей нужен тэг «вентилятор», потому как кипение и бурление практически неизбежно
Я вовсе не хотел кого-то провоцировать на спор. Прошу принять мои извинения, если я кому-то ненароком сделал неприятно.
Сейчас я работаю в проекте по созданию языка достаточно общего назначения. Поэтому данная статистика для меня очень важна.
Сейчас я работаю в проекте по созданию языка достаточно общего назначения. Поэтому данная статистика для меня очень важна.
Лично во мне этот вопрос не вызывает никакого кипения, может по тому, что я пробовал и то и другое…
второй, но не "(число пробелов в начале)", а табуляция в моем случае.
Основной критерий — это исключение исчерпывающих элементов описания в коде, для удобства чтений/написания так или иначе делаю отступы в блоках. Зачем в таком случае {} если уже есть «логические» отступы так и с остальным избыточным синтаксисом языков например: в php два символа => для присвоения значения вместо :, array() вместо [] (да в последнем релизе добавили) и так далее и тому подобные конструкции следует упрощать.
Основной критерий — это исключение исчерпывающих элементов описания в коде, для удобства чтений/написания так или иначе делаю отступы в блоках. Зачем в таком случае {} если уже есть «логические» отступы так и с остальным избыточным синтаксисом языков например: в php два символа => для присвоения значения вместо :, array() вместо [] (да в последнем релизе добавили) и так далее и тому подобные конструкции следует упрощать.
Конечно отступы. Python-way и все дела. Бритва Оккама призывает не плодить лишних сущностей, а хороший и читабельный код итак вполне наполнен отступами.
Мне всегда было интересно, вот есть у меня такой код
А теперь мне надо обернуть это всё во внешний цикл по b. В C подобных достаточно поставить скобочки и цикл готов, а в питоне надо на каждой сточке ставить пробелы. А если строчек сотня?
for a in x
print a+b
А теперь мне надо обернуть это всё во внешний цикл по b. В C подобных достаточно поставить скобочки и цикл готов, а в питоне надо на каждой сточке ставить пробелы. А если строчек сотня?
На практике и в том, и в другом языке надо будет все равно сдвинуть внутренний цикл вправо. В Си, конечно, теоретически можно не сдвигать, но тогда код будет нечитабелен.
В C это вопрос укашательств. Заставить работать «по-быстрому» вполне можно.
Плюс к тому, иногда несколько циклов исполняются в паре, например
Я не вижу тут смысла ставить 2 отступа, так как по логике тут один цикл.
Плюс к тому, иногда несколько циклов исполняются в паре, например
for (int i=0; i<N; ++i) for (int j=0; j<N; ++j)
cout<<M(i,j);
Я не вижу тут смысла ставить 2 отступа, так как по логике тут один цикл.
1) > Заставить работать «по-быстрому» вполне можно.
Согласен. Это минус indentation-based варианта.
2) > Плюс к тому, иногда несколько циклов исполняются в паре, например
Ваш пример подходит и под первый, и под второй вариант ответа опроса. Я делал опрос безотносительно привязки конкретно к языку Питону. Можно представить какой-нибудь indentation-based язык, в котором приведенная вами конструкция будет корректной.
Согласен. Это минус indentation-based варианта.
2) > Плюс к тому, иногда несколько циклов исполняются в паре, например
Ваш пример подходит и под первый, и под второй вариант ответа опроса. Я делал опрос безотносительно привязки конкретно к языку Питону. Можно представить какой-нибудь indentation-based язык, в котором приведенная вами конструкция будет корректной.
Ну обычно у IDE есть плюшки для смещения блоков кода.
У Пайтона для этого есть нативные средства, чтобы сделать компактно, без потерь:
print [(x,y) for x in a for y in b]
Ну или через словарь, для разных нужд — по разному. Компактно и читабельно, что ппц. Но мы ведь не о языках, правда? =)
Хороший код всегда читабелен и хорошо структурирован, а компилятору/интерпретатору, в целом, до одного места, сколько там строк, отступов и т.д.
Если хочется писать плохо читаемый код, чтобы… эм… экономить строки, — пусть судьей вам будет тот, кто этот код дальше будет поддерживать.
Рассуждения всё-равно упрутся в языки и их реализацию, их средства. Но «бритву» не обманешь…
print [(x,y) for x in a for y in b]
Ну или через словарь, для разных нужд — по разному. Компактно и читабельно, что ппц. Но мы ведь не о языках, правда? =)
Хороший код всегда читабелен и хорошо структурирован, а компилятору/интерпретатору, в целом, до одного места, сколько там строк, отступов и т.д.
Если хочется писать плохо читаемый код, чтобы… эм… экономить строки, — пусть судьей вам будет тот, кто этот код дальше будет поддерживать.
Рассуждения всё-равно упрутся в языки и их реализацию, их средства. Но «бритву» не обманешь…
аможновообщеписатьоченькомпактотольковотбудетлиэточитаемо
Эм, если не ошибаюсь человек отвечал на комментарий вроде «хочу писать все в одну строчку, ибо это быстро и ни за что не перенесу строку кода, хотя этого требуют правила»
Aeron вполне справедливо заметил, что те, кто презирают переносы строк, могут точно также писать говнокод и на второй группе языков.
В любом случае, вот это вот:
Aeron вполне справедливо заметил, что те, кто презирают переносы строк, могут точно также писать говнокод и на второй группе языков.
В любом случае, вот это вот:
for (int i=0; i<N; ++i) for (int j=0; j<N; ++j)
cout<<M(i,j);Не читаемо ни капли, так же как и сложные списковые выражения в питоне.
Именно об я и говорю, это надо писать так:
и только так. А иначе вы обрекаете читающего и рефакторивающего ваш код на лишнею работу.
for (int i=0; i<N; i++)
{
for (int j=0; j<N; j++)
{
cout << M(i, j);
}
}
и только так. А иначе вы обрекаете читающего и рефакторивающего ваш код на лишнею работу.
блин, редактор тут явно не интеллектуальный съел все отступы
for (int i = 0; i < N; i++)
{
for (int j = 0; j < N; j++)
{
cout << M(i, j);
}
}
IMHO для данного случая можно и так:
А вот если строк в теле цикла больше одной, то с скобками как-то читабельнее.
for (int i=0; i<N; i++)
for (int j=0; j<N; j++)
cout << M(i, j);А вот если строк в теле цикла больше одной, то с скобками как-то читабельнее.
Опс… тэг code поставил, но отступы все равно ушли. А по замыслу должны быть.
Во, во… проходили
следуем совету выше Use the «source» tag, Luke ;)
Это не плохо, для чтения. Но плохо при рефакторинге. Допустим надо добавить вторую строку к циклу. И сразу придется расставить все скобки. Это в лучшем случае, а никогда не встречались когда добавляешь вторую строку дальше и тупо не понимаешь почему она не выполняется в цикле :)
следуем совету выше Use the «source» tag, Luke ;)
for (int i=0; i<N; i++)
for (int j=0; j<N; j++)
cout << M(i, j);
Это не плохо, для чтения. Но плохо при рефакторинге. Допустим надо добавить вторую строку к циклу. И сразу придется расставить все скобки. Это в лучшем случае, а никогда не встречались когда добавляешь вторую строку дальше и тупо не понимаешь почему она не выполняется в цикле :)
А если прорефакторишь так
то у читающего (а у вас со временем) есть все шансы не понять почему цикл выполняется больше чем нужно, т.к. при большом теле второго цикла, очень мало придешь внимания первой строке без скобок. Это психология :)
for (int i=0; i<N; i++)
for (int j=0; j<N; j++)
{
cout << M(i, j);
...
M();
}
то у читающего (а у вас со временем) есть все шансы не понять почему цикл выполняется больше чем нужно, т.к. при большом теле второго цикла, очень мало придешь внимания первой строке без скобок. Это психология :)
Ну это уже дело привычки и вкуса. В своем софте я пишу так и добавлять {} потом не сложно (да и очень редко приходится такое делать). А если забыть {}, то редактор сдвинет новую строку влево. Это будет заметно.
На всякий случай отмчеу, что я пишу так если в проекте не задан стандарт кодированя. Если есть — то и вопроса нет в принцие.
На всякий случай отмчеу, что я пишу так если в проекте не задан стандарт кодированя. Если есть — то и вопроса нет в принцие.
Ваш замысел не совпал с замыслом авторов HTML, тег code по их замыслу чисто семантический, обработка пробелов и перевода строк никак не отличается от стандартной (в отличии от тега pre):
Phrase elements add structural information to text fragments. The usual meanings of phrase elements are following:
…
CODE:
Designates a fragment of computer code.
The code element represents a fragment of computer code.
Phrase elements add structural information to text fragments. The usual meanings of phrase elements are following:
…
CODE:
Designates a fragment of computer code.
The code element represents a fragment of computer code.
Как раз для таких случаев скобки лучше +). Ну вот пропали отступы. Вся логика приложения, в котором синтаксис основан на отступах умерла.
Над проектом работает несколько человек, у каждого свой вид отступов (пробелы-табы), у одного табы 4 пробела, у другого 2. Геморой вечный.
Все решается, но зачем решать проблемы которых в принципе не должно быть?
Над проектом работает несколько человек, у каждого свой вид отступов (пробелы-табы), у одного табы 4 пробела, у другого 2. Геморой вечный.
Все решается, но зачем решать проблемы которых в принципе не должно быть?
В проекте должно быть соглашение по таким вещам. Иначе, если проект большой или международный, каша будет всех бесить. Что бы разработчики не говорили, разницы между табами и пробелами нет никакой с точки зрения результата. А посему в таких вопросах можно просто бросить монетку и выбрать что-то одно.
Стандартной практикой, насколько мне известно является принуждение или приведение к едином стилю на уровне системы контроля версий.
А про «потерю отступов»… Так это вы просто с потолка взяли. Что-то не помню ни за собой, ни за кем-либо подобного коммита, ни в Java, ни в С++, ни в Python.
Стандартной практикой, насколько мне известно является принуждение или приведение к едином стилю на уровне системы контроля версий.
А про «потерю отступов»… Так это вы просто с потолка взяли. Что-то не помню ни за собой, ни за кем-либо подобного коммита, ни в Java, ни в С++, ни в Python.
От безумия лечит чтение PEP’ов перед сном, особенно 8-го… в данном случае.
for x, y, z in product((1,2,3), (4,5,6), (7,8,9)):
print x + y * z
Выделить и нажать tab, не? =)
Остальное ide/редактор сделает за вас.
Остальное ide/редактор сделает за вас.
в качестве ide используется ed/notepad по выбору.
Выделить блок и Tab нажать. Или вы в notepad'е код пишете?
Если вам нужно обернуть сотню строчек в цикл — язык, возможно, последняя из проблем, которые перед вами стоят.
Это из раздела: какая музыка лучше?
Какая разница какой синтаксис удобнее? Или Вы предлагаете возможность предоставить измененный синтаксис для всех языкв программирования? К примеру, если выберут «Like A Python», то Вы предоставите в PHP, C и прочих «фигурных» синтаксисов альтернативный? Нет? Значит какой смысл в этом опросе, кроме холивара естественно.
Какая разница какой синтаксис удобнее? Или Вы предлагаете возможность предоставить измененный синтаксис для всех языкв программирования? К примеру, если выберут «Like A Python», то Вы предоставите в PHP, C и прочих «фигурных» синтаксисов альтернативный? Нет? Значит какой смысл в этом опросе, кроме холивара естественно.
Я проектирую DSL языки, например. Так что для меня эта статистика имеет практический смысл.
DSL-язык — так же ужасно, как VIP-персона.
(E-DSL, что ли?)
Вообще же, эта статистика для вас не имеет смысла, потому что не отражает вашу аудиторию (вероятно). DSL по своему назначению попадают на длииииииинную шкалу от сугубо технических пользователей, которые могут научиться писать на чем угодно, и которые вам тут и отвечают и до сугубо бизнес-пользователей, которым скобки (кроме формул) поперек горла. Для последних, кстати, иногда блоки вообще непонятны в любом виде.
Вообще же, эта статистика для вас не имеет смысла, потому что не отражает вашу аудиторию (вероятно). DSL по своему назначению попадают на длииииииинную шкалу от сугубо технических пользователей, которые могут научиться писать на чем угодно, и которые вам тут и отвечают и до сугубо бизнес-пользователей, которым скобки (кроме формул) поперек горла. Для последних, кстати, иногда блоки вообще непонятны в любом виде.
Всё равно.
С одной стороны скобки-то и не нужны, ибо каждый нормальный программист форматирует код отступами. Причём по тем же правилам что и во второй группе языков.
Но в то же время скобки вносят какой-то порядок, что ли.
К примеру, куда удобнее отслеживать начало и конец блока, особенно в современных IDE, в которых наводишь на закрывающую скобку курсор и тебе подсвечивают уровень скобки + показывают фрагмент начала блока в отдельной небольшой панельке.
С одной стороны скобки-то и не нужны, ибо каждый нормальный программист форматирует код отступами. Причём по тем же правилам что и во второй группе языков.
Но в то же время скобки вносят какой-то порядок, что ли.
К примеру, куда удобнее отслеживать начало и конец блока, особенно в современных IDE, в которых наводишь на закрывающую скобку курсор и тебе подсвечивают уровень скобки + показывают фрагмент начала блока в отдельной небольшой панельке.
Подсветку блока, кстати, можно сделать и без скобок. Например, ставишь курсор на блок — фон его кода чуть-чуть изменяется.
Завязывать язык на IDE?
В данном случае мы обсуждали не зависимость языка от IDE, а зависимость возможностей IDE от дизайна языка.
нет IDE, вот нет вообще.
Мне кажется, это немного не относится к данной нити дискуссии.
нет IDE, вот нет вообще
Только глиняная табличка и зубило?
Ну если нет IDE, так отступы хорошо видны в любом случае. Они у вас есть и со скобками, и без.
А если у вас вложенность блоков, циклов и прочих радостей порядка 7-10 штук, то никакая IDE не поможет вам разобраться в этом мусоре. Или конструкции вида }\n\t}\n\t\t}\n\t\t\t} вам сильно помогают?
А если у вас вложенность блоков, циклов и прочих радостей порядка 7-10 штук, то никакая IDE не поможет вам разобраться в этом мусоре. Или конструкции вида }\n\t}\n\t\t}\n\t\t\t} вам сильно помогают?
Есть еще языки без significant whitespace, но при этом без скобок. См. Erlang
НЛО прилетело и опубликовало эту надпись здесь
Я просто кончаю от Scala, языка прекрасней (а там C-подобный синтаксис) лично я не видел.
У каждого свои эрогенные зоны.
www.tryerlang.org/
К сожалению, содержимое ресурса не соответствует теме дискуссии, но доменное имя все же вполне уместно.
К сожалению, содержимое ресурса не соответствует теме дискуссии, но доменное имя все же вполне уместно.
Ага… Взяли ключевые проблемы Java, добавили туда богатство Common Lisp и получили стандарт длиннее С++-ого. Волшебство…
НЛО прилетело и опубликовало эту надпись здесь
На правах придирки:
Наверное вы имели в виду выравнивание на уровне IDE?
Все-таки компилятор несколько другим занимается, и даже не все языки из списка в опросе — компилируемые.
Наверное вы имели в виду выравнивание на уровне IDE?
Все-таки компилятор несколько другим занимается, и даже не все языки из списка в опросе — компилируемые.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Транслятор :) Сейчас для многих языков понятия интерпретатор и компилятор сливаются. Java или C# компилируемые языки (можно предположить по сценариям использования) или интерпретируемые (если влезать внутрь, то компиляция происходит в байт-код, который интерпретируется виртуальной машиной, причём такая интерпретация может заключаться в компиляции в нативный код)? А PHP или Python, программы на которых также компилируются в байт-код, только неявно для разработчика.
Мне вот удобно писать на c#, bash, python.
мне python взорвал мозг, когда у меня был вызов конструктора с кучей параметров, так и не врубился как одну строчку вызова разнести на несколько.
не подскажите, адепты?
не подскажите, адепты?
Справедливости ради надо заметить, что Haskell позволяет и вариант со скобками.
По большому счету по фиг.
Однако оформлять код отступами можно даже в языках с {}
А вот оформлять код {} в языках с отступами невозможно.
Часть меньше целого.
Однако оформлять код отступами можно даже в языках с {}
А вот оформлять код {} в языках с отступами невозможно.
Часть меньше целого.
С пробелами, конечно же, компактнее и читабельнее получается. Но код с {} можно куда угодно копипастить — он всё равно компилироваться будет. Это удобно для форумов всяких и e-mail'ов.
Не вижу различий в удобстве, даже если они и были, то если работать хоть в сколько-нибудь нормальном редакторе кода, все нивелируется.
Могу только сказать, что код с отступами не получится сжать так же хорошо, как с парными элемнтами, правда это никому это и не нужно, кроме браузерных языков и в данном случае яваскрипту
Могу только сказать, что код с отступами не получится сжать так же хорошо, как с парными элемнтами, правда это никому это и не нужно, кроме браузерных языков и в данном случае яваскрипту
Благодарю вас за конструктивный комментарий.
Приведите, пожалуйста, статистику по компрессии.
В комментарии я имел ввиду сжатие написанного кода, а не файла с исходным кодом. Для компилируемых языков и интерпретируемых на сервере, это практически не имеет смысла. Остаются интерпретируемые на клиенте, а из низ них у нас живым можно признать только javascript.
Так вот, если бы яваскрипт использовал не парные элементы, а оступы, то он бы сжимался хуже по той причине, которую проще пояснить на примере:
У нас есть блок кода из r строк, вложенностью n. Для простоты расчетов, на всех предыдущих уровнях вложенности только по одной строке.
В случае яваскрипта, мы используем n открывающих и n закрывающих скобок + один символ (точка с запятой) для каждой внутренне строки. Итого: n*2 + r
Для синтаксиса с отступами, у нас в каждой строке будет нарастать кол-во символов оступа 0+1+2+...+n-1= (n-1)*n/2 оступов до того как мы доберемся до нашего блока кода. Приэтому каждая новая строка подразумевает символ перевода строки, т.е еще n символов перевода строки. Дальше на каждую строку n символов отступа. Итого: (n-1)*n/2 + n + n*r
При вложенности 1 для одной строки мы получаем 3 против 2. Но если вложенность два то уже 5 против 5.
Как можно видеть, количество символов отвечающих за вложенность в первом случае растет линейно, а во втором квадратично (для n>1), а значит если вложенность больше единицы n>1, то второй способ занимает больше (если точнее одинаково для одной строки r=1, дальше больше).
Я понимаю, что тут рассмотрено совсем абстрактно, и синтаксисы разные бывают, где-то условиям надо ставить круглые скобки где-то нет, но в любом случае, квадратичная зависимость даст о себе знать достаточно быстро
Так вот, если бы яваскрипт использовал не парные элементы, а оступы, то он бы сжимался хуже по той причине, которую проще пояснить на примере:
У нас есть блок кода из r строк, вложенностью n. Для простоты расчетов, на всех предыдущих уровнях вложенности только по одной строке.
В случае яваскрипта, мы используем n открывающих и n закрывающих скобок + один символ (точка с запятой) для каждой внутренне строки. Итого: n*2 + r
Для синтаксиса с отступами, у нас в каждой строке будет нарастать кол-во символов оступа 0+1+2+...+n-1= (n-1)*n/2 оступов до того как мы доберемся до нашего блока кода. Приэтому каждая новая строка подразумевает символ перевода строки, т.е еще n символов перевода строки. Дальше на каждую строку n символов отступа. Итого: (n-1)*n/2 + n + n*r
При вложенности 1 для одной строки мы получаем 3 против 2. Но если вложенность два то уже 5 против 5.
Как можно видеть, количество символов отвечающих за вложенность в первом случае растет линейно, а во втором квадратично (для n>1), а значит если вложенность больше единицы n>1, то второй способ занимает больше (если точнее одинаково для одной строки r=1, дальше больше).
Я понимаю, что тут рассмотрено совсем абстрактно, и синтаксисы разные бывают, где-то условиям надо ставить круглые скобки где-то нет, но в любом случае, квадратичная зависимость даст о себе знать достаточно быстро
Я тоже про исходинки. У вас есть некоторая ошибка в подсчёте.
Алгоритмы сжатия без потерь (например, gzip и bzip2) пакуют байты исходя из статистической избыточности кода. Поэтому, во многих случаях уровень отступа блока не несёт описанной вами избыточности (n-1)*n/2 + n + n*r.
Допустим, что на устранение статистической избыточности алгоритм выделяет 1 байт. Тогда, в условные 2 байта (1:sequence_len, 2:sequence_char) мы сможем уместить описание отступа в 256 пробелов. Значит:
— если алгоритм при подсчете скобок также выделяет 2 байта (первый — на подсчёт количества повторяющихся скобок, второй — символ скобки), то мы не получим никакой разницы при компрессии.
— если для каждой скобки выделяется отдельный байт, то качества сжатия зависит от числа повторяющихся скобок. Сжатие может оказаться как лучше, так и хуже. С точки зрения абстрактного примера, такую погрушность следует интерпретировать как — «нет никакой разницы».
— количество символов новой строки, в общем случае (т.е. с учетом, что не проводилась предварительная «минимизация» кода), будет равна либо очень близка к количеству открывающих скобок.
Описанный выше пример — это «базовая» упаковка на уровне отдельных последовательностей ЯВНО повторяющихся символов. Современные алгоритмы сжатия без потерь способны выявлять и более крупные блоки-шаблоны, а также производить упаковку уже упакованных последовательностей. Как раз за такую дополнительную оптимизацию отвечают так называемые «уровни компрессии» (например, «gzip -9 / bzip -9»).
После своего первого комментария, я попробовал сравнить сжатие питоновского модуля фреймворка Bottle, размером в 127474 байт (127КБ), и сжатие минимизированного фразмента (такой же длины) библиотеки jquery-ui.
Вот цифры:
— 36569 bottle_gz.py
— 31007 test.js.gz
— = 5562 (5.43KB) == 1/23 per byte == 4.36%
— 31579 bottle.py.bz2
— 26494 test.js.bz2
— = 5085 (4.97KB) == 1/25 per byte == 3.989%
Мне кажется, что ваш довод про «код с отступами не получится сжать так же хорошо, как с парными элемнтами» можно засчитать с оооочень большой натяжкой. Потому что такие накладные расходы, в некоторых случаях, будут сопоставимы с затратами на повторную пересылку потерянных сетевых пакетов.
Алгоритмы сжатия без потерь (например, gzip и bzip2) пакуют байты исходя из статистической избыточности кода. Поэтому, во многих случаях уровень отступа блока не несёт описанной вами избыточности (n-1)*n/2 + n + n*r.
Допустим, что на устранение статистической избыточности алгоритм выделяет 1 байт. Тогда, в условные 2 байта (1:sequence_len, 2:sequence_char) мы сможем уместить описание отступа в 256 пробелов. Значит:
— если алгоритм при подсчете скобок также выделяет 2 байта (первый — на подсчёт количества повторяющихся скобок, второй — символ скобки), то мы не получим никакой разницы при компрессии.
— если для каждой скобки выделяется отдельный байт, то качества сжатия зависит от числа повторяющихся скобок. Сжатие может оказаться как лучше, так и хуже. С точки зрения абстрактного примера, такую погрушность следует интерпретировать как — «нет никакой разницы».
— количество символов новой строки, в общем случае (т.е. с учетом, что не проводилась предварительная «минимизация» кода), будет равна либо очень близка к количеству открывающих скобок.
Описанный выше пример — это «базовая» упаковка на уровне отдельных последовательностей ЯВНО повторяющихся символов. Современные алгоритмы сжатия без потерь способны выявлять и более крупные блоки-шаблоны, а также производить упаковку уже упакованных последовательностей. Как раз за такую дополнительную оптимизацию отвечают так называемые «уровни компрессии» (например, «gzip -9 / bzip -9»).
После своего первого комментария, я попробовал сравнить сжатие питоновского модуля фреймворка Bottle, размером в 127474 байт (127КБ), и сжатие минимизированного фразмента (такой же длины) библиотеки jquery-ui.
head -c127474 jquery-ui.min.js > test.js
gzip -c9 bottle.py > bottle.py.gz
bzip2 -c9 bottle.py > bottle.py.bz2
gzip -c9 test.js > test.js.gz
bzip2 -c9 test.js > test.js.bz2
Вот цифры:
— 36569 bottle_gz.py
— 31007 test.js.gz
— = 5562 (5.43KB) == 1/23 per byte == 4.36%
— 31579 bottle.py.bz2
— 26494 test.js.bz2
— = 5085 (4.97KB) == 1/25 per byte == 3.989%
Мне кажется, что ваш довод про «код с отступами не получится сжать так же хорошо, как с парными элемнтами» можно засчитать с оооочень большой натяжкой. Потому что такие накладные расходы, в некоторых случаях, будут сопоставимы с затратами на повторную пересылку потерянных сетевых пакетов.
Я понимаю вашу идею, и спасибо за проведенное исследование и его подробный разбор.
Но все же мы говорим о разных вещах, виной тому скорее всего употребление мной термина «сжатие», правильнее я думаю было бы назвать это «минимизация+обфускация».
Чисто теоретически по приведенному мной рассчету, код с парными блоками при прочих равных условиях можно написать короче в смысле количества символов. Так как это нечитаемо, то пишут все, конечно, нормально, а дальше его минимизируют. В этом случае вырезаются лишние символы, комментарии, названия используемых переменных заменяются на максимально короткие и т.п. Некоторые минимизаторы-обфускаторы, используют сжатие со словарем (packer).
Собственно для js стандартной практикой является предварительная минимизация, а далее сжатие гзипом. Гзип, конечно, очень мощный и по сути делает предварительную минимизацию необязательной, но все же выигрыш есть, и он растет с увеличением исходного файла (раз, два).
В итоге я хотел сказать, что если бы в javascript блоки определялись отступами, файлы после минимизации и сжатия весили бы больше.
В масштабах всего интернета, пожалуй, это бы вылилось в значительные объемы лишних данных=)
Но все же мы говорим о разных вещах, виной тому скорее всего употребление мной термина «сжатие», правильнее я думаю было бы назвать это «минимизация+обфускация».
Чисто теоретически по приведенному мной рассчету, код с парными блоками при прочих равных условиях можно написать короче в смысле количества символов. Так как это нечитаемо, то пишут все, конечно, нормально, а дальше его минимизируют. В этом случае вырезаются лишние символы, комментарии, названия используемых переменных заменяются на максимально короткие и т.п. Некоторые минимизаторы-обфускаторы, используют сжатие со словарем (packer).
Собственно для js стандартной практикой является предварительная минимизация, а далее сжатие гзипом. Гзип, конечно, очень мощный и по сути делает предварительную минимизацию необязательной, но все же выигрыш есть, и он растет с увеличением исходного файла (раз, два).
В итоге я хотел сказать, что если бы в javascript блоки определялись отступами, файлы после минимизации и сжатия весили бы больше.
В масштабах всего интернета, пожалуй, это бы вылилось в значительные объемы лишних данных=)
Эффективно обфусцировать наверное тоже не получится :)
Не смог начать себя приучать к питону тупо из-за невозможности уместить в своей голове стандартный ход вещей: тут — точка с запятой, там — скобки. IDE сам форматирует всё как нужно.
Не мотивирует даже вся мощь джанги, гораздо более высокие гонорары и меньшая конкуренция.
Не мотивирует даже вся мощь джанги, гораздо более высокие гонорары и меньшая конкуренция.
Честно говоря, даже не понимаю тех, кто считает, что выравнивать пробелами, которых не видно, лучше, чем реальными скобками. Это также относится к псевдостилю вида
public void MyMethod() {
…
}
Ну, как это можно читать — когда взгляд ищет блок в скобках, а для этого на до выискивать открывающиесю скобку, вместо того, чтобы просто пробежать взглядом по вертикали.
public void MyMethod() {
…
}
Ну, как это можно читать — когда взгляд ищет блок в скобках, а для этого на до выискивать открывающиесю скобку, вместо того, чтобы просто пробежать взглядом по вертикали.
Оно компактнее, больше шансов охватить всю функцию одним взглядом. Как результат — много удобнее, особенно если какой-то алгоритм сложный
Как раз наоборот, я тут один код рефакторил, так это просто бред — куча вложенных if в перемешку с циклами и case и все это на 3 экрана — в таком стиле это все равно, что не форматированная куча текста, где ни конца ни начало нет. Пока не отформатировал как нужно — смысл был совершенно не ясен.
Со скобкой на следующей строке имхо только еще хуже мешанина выходит. Но не будем забывать, что на вкус или цвет фломастеры разные.
Думаю дело не во вкусе. Как говорил выше, с выровненными скобками по вертикали блок виден целиком, и ошибиться где он начинается практически не возможно, в отличии когда первой скобки нет, и приходится думать — где же она и судорожно искать по всему тексту, желая убедится, что это в цикле, а не в условии выше, например.
Поднимаешься по столбцу вверх и тебя встречает сразу оператор, ради которого эта скобка и открывалась. А не две бессмысленые строчки — оператор, а потом еще и скобка. И оба на одном столбце. Если очень хочется сворачивать, умные IDE без проблем сворачивают оба варианта.
А еще рекомендую глянуть какой-нить astyle, он вам автоматом скобки переставит в том стиле, какой вам нравится.
Кстати, посмотрите у него (по ссылке) стили whitesmith, banner, gnu, horstmann. Довольно забавные варианты оформления, хотя я бы такой не принял. Мне больше всего по душе стиль k&r и подобные.
А еще рекомендую глянуть какой-нить astyle, он вам автоматом скобки переставит в том стиле, какой вам нравится.
Кстати, посмотрите у него (по ссылке) стили whitesmith, banner, gnu, horstmann. Довольно забавные варианты оформления, хотя я бы такой не принял. Мне больше всего по душе стиль k&r и подобные.
Не случайно там стиль ansi идет первым :) Все остальное — это муть…
Особенно вот этот прикол
} else
попробуйте угадать что вас ждет, когда вы подниметесь вверх от закрывающейся скобки — оператор то тю-тю…
Особенно вот этот прикол
} else
попробуйте угадать что вас ждет, когда вы подниметесь вверх от закрывающейся скобки — оператор то тю-тю…
Впрочем даже ansi плох, а вот стиля вида
я там не нашел. А он самый толковый.
int Foo(bool isBar)
{
if (isBar)
{
bar();
return 1;
}
else
{ return 0; }
}
я там не нашел. А он самый толковый.
Отвратительный стиль, имхо. Куда лучше смотрится следующее:
Компактно, бессмысленные скобки не занимают лишнее место, ярко видно уровни.
int Foo(bool isBar) {
if (isBar) {
bar();
return 1;
} else {
return 0;
}
}
Компактно, бессмысленные скобки не занимают лишнее место, ярко видно уровни.
Человек видимо C# увлекается, судя по форматированию кода и методу с заглавной. Я тоже не признаю такого дикого стиля расстановки скобок.
Жаль это не JS, а то бы убрали несколько лишних скобок :)
Жаль это не JS, а то бы убрали несколько лишних скобок :)
int Foo(bool isBar) {
return isBar ? (bar(),1) : 0;
}
Я уже говорил — это не читаемо
Вот выше я объяснил, почему это плохо, а Вы можете аргументировать чем это может быть удобно?
> Компактно, бессмысленные скобки не занимают лишнее место, ярко видно уровни.
1. компакто
— Вот признайтесь вы всегда читаете книги написанные 6 шрифтом? Очень компактно. Зачем вам компактность при написании кода? Хард маленький?
2. уровни видно
— извиняюсь где? Здесь не видно ни границы процедуры, ни окончания условия, ни тем более блока «иначе». Скобки гуляют как хотят. else на одном уровне с операторами внутри if — т.е. выравнивания вообще нет. Зачем вы тогда вообще пробелы используете? Для какой цели?
3. бессмысленные скобки не занимают лишнее место
— т.е. вам скобки только мешают, и вы не знаете куда их засунуть — ок, видно по коду. Но вообще не пробовали думать для чего нужны скобки?
1. компакто
— Вот признайтесь вы всегда читаете книги написанные 6 шрифтом? Очень компактно. Зачем вам компактность при написании кода? Хард маленький?
2. уровни видно
— извиняюсь где? Здесь не видно ни границы процедуры, ни окончания условия, ни тем более блока «иначе». Скобки гуляют как хотят. else на одном уровне с операторами внутри if — т.е. выравнивания вообще нет. Зачем вы тогда вообще пробелы используете? Для какой цели?
3. бессмысленные скобки не занимают лишнее место
— т.е. вам скобки только мешают, и вы не знаете куда их засунуть — ок, видно по коду. Но вообще не пробовали думать для чего нужны скобки?
Зачем вам компактность при написании кода?
Код иногда приходится и читать и лишние строки со скобками явно не способствуют тому, чтобы один логический блок помещался на одном экране.
скобки только мешают, и вы не знаете куда их засунуть — ок, видно по коду. Но вообще не пробовали думать для чего нужны скобки?
Чтобы транслятор понял где блок начинается, а где кончается. А человеку они мешают, вот и мучается народ со стилями кода распихивая их, чтоб не мешали )
Код иногда приходится и читать и лишние строки со скобками явно не способствуют тому, чтобы один логический блок помещался на одном экране.
скобки только мешают, и вы не знаете куда их засунуть — ок, видно по коду. Но вообще не пробовали думать для чего нужны скобки?
Чтобы транслятор понял где блок начинается, а где кончается. А человеку они мешают, вот и мучается народ со стилями кода распихивая их, чтоб не мешали )
> int Foo(bool isBar) {
И еще ответь на вопрос — какой тут сакральный смысл несет фигурная скобка, поставленная зачем то к конце. Какой от неё прок?
И еще ответь на вопрос — какой тут сакральный смысл несет фигурная скобка, поставленная зачем то к конце. Какой от неё прок?
В данный исторический момент мне больше нравится синтаксис с выделением блоков парными скобками. Использование отступа как элемента языка кажется адом, даже не считая того, что я свой код все равно отступами форматирую. Не факт что в будущем ничего не изменится.
А вот гляда на код новичков, иногда прям хочется, чтобы компилятор отказывался компилировать некрасиво отформатированный текст. Иначе просто не объяснишь зачем это надо.
А вот гляда на код новичков, иногда прям хочется, чтобы компилятор отказывался компилировать некрасиво отформатированный текст. Иначе просто не объяснишь зачем это надо.
мне нравятся языки с одним end — проще форматировать
НЛО прилетело и опубликовало эту надпись здесь
А зачем себя насиловать?
НЛО прилетело и опубликовало эту надпись здесь
Я имел опыт если что — мне без явных скобок — очень не уютно. Тогда их надо чем-то заменять. TSQL имеет явные BEGIN… END, про фокс написал ниже… но там где даже нет аналога — это мрак
впрочем можно и на ассемблере писать, но там не присмотревшись легко не поймешь — где начало цикла, а где вход в процедуру… зачем же призывать к низкоуровневому стилю?
НЛО прилетело и опубликовало эту надпись здесь
Человек должен видеть блоки, а только отступами этого не реализовать. Чтобы видеть блоки — нужны скобки И отступы.
НЛО прилетело и опубликовало эту надпись здесь
Это не мнение. Тут решается вопросу GUI для программиста :) И как видим этому мнению соответствует статистика 80%. Я же всего лишь пытаюсь найти объективные обоснования такому мнению 80%
НЛО прилетело и опубликовало эту надпись здесь
Это полторы тысячи программистов не имеют опыта работы с отступами? Это при том, что тут большое лобби функциональных языков? Сомнительно.
Ну, даже если кто-то и не имеет, то это лишь доказывает то, что он выбирает те языки, которые интуитивно более естественны
Ну, даже если кто-то и не имеет, то это лишь доказывает то, что он выбирает те языки, которые интуитивно более естественны
Нет тут никакого «функционального лобби».
это лишь доказывает то, что он выбирает те языки, которые интуитивно более естественны
Скорее импринтинг после Паскаля/Си/ПХП/ЯС, да и языков без скобочек (в том или ином виде) не так уж много среди популярных. Из мэйнстримовых вообще только Питон в голову приходит.
Скорее импринтинг после Паскаля/Си/ПХП/ЯС, да и языков без скобочек (в том или ином виде) не так уж много среди популярных. Из мэйнстримовых вообще только Питон в голову приходит.
Скажу наоборот — имею несколько сотен часов на языке в первом варианте, но проголосовал за второй.
По большому счету, разница, как форматировать, не принципиальна.
Я считаю, что большим плюсом того же Python есть то, что язык по умолчанию заставляет программиста форматировать код более понятно.
Да, многие также форматируют код языков из первой категории — с помощью IDE или редактора.
Но сколько этого не делают? Намного больше.
По большому счету, разница, как форматировать, не принципиальна.
Я считаю, что большим плюсом того же Python есть то, что язык по умолчанию заставляет программиста форматировать код более понятно.
Да, многие также форматируют код языков из первой категории — с помощью IDE или редактора.
Но сколько этого не делают? Намного больше.
Но это же не выход — делать форматирование синтаксисом языка. Это в принципе не верный подход, синтаксис языка должен быть свободен от элементов форматирования. И правильно, что форматирование — это задача редактора. Ну, было бы еще не плохо, если бы компилятор кидал бы warning при плохом форматировании, но это не должно быть причиной error
Ну выкинуло бы error, но, к примеру, кто-то сильно спешил закоммитить баг, и не было времени нормально отформатировать. Потом опять этот файл исправили, потом опять… И получилась каша.
Лучший вариант — автоматическое форматирование кода средствами IDE при коммите кода или сохранении.
Вообще, этот пост мне напомнил холивар о «табуляция или пробелы». Как я помню, все остались при своих мнениях.
Лучший вариант — автоматическое форматирование кода средствами IDE при коммите кода или сохранении.
Вообще, этот пост мне напомнил холивар о «табуляция или пробелы». Как я помню, все остались при своих мнениях.
> Лучший вариант — автоматическое форматирование кода средствами IDE при коммите кода или сохранении.
Вы в точности сказали то же что и я, но почему-то назвали это моим холиваром :)
Вы в точности сказали то же что и я, но почему-то назвали это моим холиваром :)
> «табуляция или пробелы»
Это пробелы — это вообще бред. Тоже самое, что «умножь на 4 число движений курсором вправо, и поверь, что это тебе надо.»
Это пробелы — это вообще бред. Тоже самое, что «умножь на 4 число движений курсором вправо, и поверь, что это тебе надо.»
Впрочем вот, на фоксе стиль такой
IF трата-та
…
ENDIF
Почему пишут капсом? Чтобы видеть явно операторы начала и конца. Тогда это сопоставимо со скобками. Иначе нет.
IF трата-та
…
ENDIF
Почему пишут капсом? Чтобы видеть явно операторы начала и конца. Тогда это сопоставимо со скобками. Иначе нет.
В том и недостаток простого голосования — достаточно иметь мнение, а аргументированность необязательна. Я лично воздержался, потому что из второго варианта писал только на CoffeeScript немного и ещё не определился. Но многие горазды отрицать всё отличающееся.
Хотя мне очень нравится Python c его отступами, мне сложно представить настоящие большие проекты на языках с таким синтаксисом.
Иными словами он «синтаксис с отступами» подходит для небольших программ и скриптов.
Проголосовал за первый, как более универсальный вариант.
Иными словами он «синтаксис с отступами» подходит для небольших программ и скриптов.
Проголосовал за первый, как более универсальный вариант.
Мне кажется, что второй вариант предпочтительнее. Он заставляет писать легко читаемый код, и делает слегка неудобным плохо стиль структурирования программ. Например слишком длинные процедуры или методы класса, с большим количеством вложенных циклов, например.
Скобки очень часто плохо прочитываются в чужом коде, а свободное форматирование очень часто приводит к неряшливым листингам.
Я бы ещё отметил пользу от декларативных конструкций, они сокращают объём кода и довольно наглядны.
Скобки очень часто плохо прочитываются в чужом коде, а свободное форматирование очень часто приводит к неряшливым листингам.
Я бы ещё отметил пользу от декларативных конструкций, они сокращают объём кода и довольно наглядны.
Кстати, в haskell можно и C-style фигурные скобки делать. Мало кто это использует, но можно.
(почему (забыли (про (лисп?))))
Никто не мешает спроектировать язык так, чтобы можно было делать и так, и эдак. Хочешь — форматируй скобками, хочешь — и отступами, и скобками, хочешь — только скобками. Haskell — тому пример. Этот язык эту проблему решил интересным образом: просто на некотором этапе обработки исходного кода транслятор вставляет фигурные скобки и точки с запятыми в нужных местах (в зависимости от отступов), если это не сделал программист.
Как по мне, лучше предоставить гибкость, чем насаждать.
Как по мне, лучше предоставить гибкость, чем насаждать.
Я прошу прощения, но почему-то Ctrl-V публикуетет комментарий.
Так вот. Код с отступами:
Код, который генерирует транслятор:
Так вот. Код с отступами:
-- whew, fixed it!
do first thing
if condition
then foo
else bar
third thing
Код, который генерирует транслятор:
-- the fixed version without sugar
do { first thing
; if condition
then foo
else bar
; third thing }
Скобки добавляют неопределенность стилизации, добавляя редко используемые и в принципе вредные однострочные структуры, что, несомненно, говорит о том что их отсутствие — это прогресс
Выбрал конечно скобки, но таки должно быть в языке, что-то вроде (как в Kotlin или Scala, которые я знаю):
или
Я это к тому, что иногда нужно просто вернуть одну строчку, простая функция, вот и тут кажутся { } и т.п. лишними, а иногда много пишешь + while/if/else и др. то, тут { } помогают не потеряться в блоках.
Так что, я за скобки, но в меру :)
fun doSome(): Int = 3или
fun doSome(): Int {
return 3
}Я это к тому, что иногда нужно просто вернуть одну строчку, простая функция, вот и тут кажутся { } и т.п. лишними, а иногда много пишешь + while/if/else и др. то, тут { } помогают не потеряться в блоках.
Так что, я за скобки, но в меру :)
Хрень эти ваши отступы.
Не зря в промышленности зачастую требуют оборачивать блоки в операторные скобки даже, если язык позволяет их опустить.
В простом примере скобки кажутся и не обязательными. В случае же множества вложенных циклов, условий и else, они на порядок повышают читабельность и снижают вероятность появления ошибки.
Не зря в промышленности зачастую требуют оборачивать блоки в операторные скобки даже, если язык позволяет их опустить.
В простом примере скобки кажутся и не обязательными. В случае же множества вложенных циклов, условий и else, они на порядок повышают читабельность и снижают вероятность появления ошибки.
Не зря в промышленности зачастую требуют оборачивать блоки в операторные скобки даже, если язык позволяет их опустить.
А как по мне, так такое требование как раз из-за естественности отступов для человека.
После
очень легко, по-моему, забыв поставить скобки, написать
вместо
потому и требуют сразу писать
А как по мне, так такое требование как раз из-за естественности отступов для человека.
После
if (a>b)
do_smth();
очень легко, по-моему, забыв поставить скобки, написать
if (a>b)
do_smth();
do_smth_more();
вместо
if (a>b) {
do_smth();
do_smth_more();
}
потому и требуют сразу писать
if (a>b) {
do_smth();
}
Какой-то надуманный случай. Не думаю, что IRL такое возможно.
Зато запутаться с тем какой else к какому if'у относится — запросто.
Так что скобки нужны для явного выделения блоков. Отступы с этим не особенно справляются.
И вообще, не понимаю людей, предлагающих смешивать стиль оформления кода и синтаксис языка. Это же какая каша должна быть в голове.
Зато запутаться с тем какой else к какому if'у относится — запросто.
Так что скобки нужны для явного выделения блоков. Отступы с этим не особенно справляются.
И вообще, не понимаю людей, предлагающих смешивать стиль оформления кода и синтаксис языка. Это же какая каша должна быть в голове.
>>Какой-то надуманный случай. Не думаю, что IRL такое возможно.
Вы ошибаетесь, встречал лично и не один раз в коде на C++.
После таких идиотских ошибок в упор не понимаю зачем нужна такая конструкция без скобок.
Это просто еще один вариант выстрелить себе в ногу, который в моей команде, слава богу, запрещен соглашение о кодировании.
Вы ошибаетесь, встречал лично и не один раз в коде на C++.
После таких идиотских ошибок в упор не понимаю зачем нужна такая конструкция без скобок.
Это просто еще один вариант выстрелить себе в ногу, который в моей команде, слава богу, запрещен соглашение о кодировании.
Думаю, скобки удобнее. Да конечно во первых это — привычка, если уже привык к ним, то остальное, наверное, будет казаться уже не столь удобным.
Но тут есть еще второй момент — практичность, т.е. если я, например, захочу по чату передать фрагмент программы, то вся логика может пострадать из-за того что какие-то пробелы/табы проглотились. Т.е. я считаю, что логика программы не должна зависеть от форматирования текста этой программы, потаму что это логически разные понятия, а ввод любой дополнительной зависимости — обычно накладывает дополнительные ограничения.
Но тут есть еще второй момент — практичность, т.е. если я, например, захочу по чату передать фрагмент программы, то вся логика может пострадать из-за того что какие-то пробелы/табы проглотились. Т.е. я считаю, что логика программы не должна зависеть от форматирования текста этой программы, потаму что это логически разные понятия, а ввод любой дополнительной зависимости — обычно накладывает дополнительные ограничения.
Согласен, что от форматирования зависеть не должно, но скобки (begin/end тоже к ним относится) тоже напрягают, причём не столько при написании кода, сколько при чтении. По хорошему транслятор сам должен догадываться где заканчивается блок- единственный вариант, что в голову приходит — отсутствие блоков в принципе )
В голосовалке не хватает третьего варианта.
«Структурные блоки определяются Непарными элементами(If EndIF, For Next и т.п.)»
«Структурные блоки определяются Непарными элементами(If EndIF, For Next и т.п.)»
Эстафета дебильных опросов перехвачена. Поздравляю!
я тут со структурными блоками на днях так задолбался. скобка не там оказалась.
на мой взгляд лучше всего максимально жестко. с маркерами
if mywish: a>5
…
endif mywish
на мой взгляд лучше всего максимально жестко. с маркерами
if mywish: a>5
…
endif mywish
Возможность обозначить блок скобками (в том числе и написать в одну строку) быть должна.
Возможность сделать то же самое отступами — приятное дополнение, как в Haskell.
Возможность сделать то же самое отступами — приятное дополнение, как в Haskell.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какой тип синтаксиса языков программирования удобнее?