Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо
Если рассматривать этот вопрос под углом зрения программиста привыкшего к сишному синтаксису, то несомненно отрицательно. Привычка есть привычка и без особых на то причин ее ломать не хочется.
Именно по этой причине немерле так легко дается сишникам, а F# — нет. Сематнически немерл как раз ближе к F# чем к C#, но синтаксис и многие другие детали (перегрузка, приведения типов и т.п.) мимикрируют под C#, что делает изучения языка "сишниками" значительно более простым занятием.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В качестве альтернативного решения вспоминается Go, если я правильно понял его грамматику, где в подобных выражениях круглые скобочки являются необязательными, а вот фигурные — необходимы в любом случае:
Я бы предпочел с точностью на оборот.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Довольно значительное число людей берут позицию авторов Go в качестве стандарта кодирования на других си-подобных языках, надеюсь, не надо рассказывать про возможные ошибки при неиспользовании фиг. скобок.
Над. И очень!
Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".
Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл
Во-вторых, я всегда ставлю все кавыки по причине, отличной от возможных ошибок из-за забытых скобок (да, бывают такие причины), хотя несколько раз такие ошибки (с забытыми скобками и сдвинутым текстом) встречал у много более опытных и не менее, чем я, скурпулёзных программистов
В-третьих, неужели ты действительно не веришь, что таких ошибок не может быть? А раз они могут быть, то чем плох такой способ борьбы с ними?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Курилка, Вы писали:
ВВ>>Само собой при сохранении остальной си-подобности.
К>И без фигурных скобок и с вытекающими их этого последствиями?
А что могут быть за "последствия"?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу.
А можно ссылочку?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
VD>>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".
_FR>Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл
Ну, я как-то думал, что трудно не заметить того, что нарвался на проблемы. Нет?
_FR>Во-вторых, я всегда ставлю все кавыки по причине, отличной от возможных ошибок из-за забытых скобок (да, бывают такие причины),
Что за "кавыки"? И как они влияют на скобки?
И что за проблемы? Ну, и почему я их ни разу в жизни не видел? Может быть для этого нужно использовать старые компиляторы и писать в ноотпэде?
_FR>хотя несколько раз такие ошибки (с забытыми скобками и сдвинутым текстом) встречал у много более опытных и не менее, чем я, скурпулёзных программистов
А IDE ты ты не встречал? Они обычно умеют показывать где проблемы с незакрытыми скобками.
И опять же причем тут не закрытые скобки и отсутствие скобок в тех местах где они не нужны?
_FR>В-третьих, неужели ты действительно не веришь, что таких ошибок не может быть? А раз они могут быть, то чем плох такой способ борьбы с ними?
Я не считаю, что проблемы — это предмет веры. Они или есть, или нет. Если у меня есть выражение:
when (a)
b();
то проблем от того что я не поставлю скобки не будет. А вот сами скобки будут совершенно лишними. Их наличие и код сделает длиннее, и введет заблуждение (если код не примитивный), так как я уже не смогу однозначно сказать один оператор в этом when или два, просто неграмотно отформатирован.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу. VD>А можно ссылочку?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали: ВВ>>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях. Например, вместо VD>Если рассматривать этот вопрос под углом зрения программиста привыкшего к сишному синтаксису, то несомненно отрицательно. Привычка есть привычка и без особых на то причин ее ломать не хочется.
Ох, не знаю. Если бы все так было просто с этими привычками, то люди бы никогда не разводились
Я вот замечаю, что меня начинают подзадалбывать все эти скобочки. А может быть, я не одинок?
VD>Именно по этой причине немерле так легко дается сишникам, а F# — нет. Сематнически немерл как раз ближе к F# чем к C#, но синтаксис и многие другие детали (перегрузка, приведения типов и т.п.) мимикрируют под C#, что делает изучения языка "сишниками" значительно более простым занятием.
Честно говоря, что не нравится в синтаксисе Немерле так это именно имитация сишного синтаксиса зачастую с нарушением привычной семантики. Например, взять операции инкремента/пост-инкремента ( хотя это макросы, наверное? ). Или те же фигурные скобочки:
match (expr) {
| x => ...
| _ => ...
}
В Си-подобных языках скобочки всегда задают лексический скоп, но в случае с match-ем — это не так. Скоп задается на уровне каждого вхождения матча, а не всего матча в целом.
С практической т.з. это все фигня, но... гм... с эстетической...
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Писать скобки в случае одного выражения или не писать — это тема для отдельного флейма и вроде как такой флейм тут недавно был, смысла в его продолжении я не вижу. VD>>А можно ссылочку?
ВВ>http://rsdn.ru/forum/flame.comp/3781310.1.aspx
Здравствуйте, VladD2, Вы писали:
VD>>>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия". _FR>>Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл VD>Ну, я как-то думал, что трудно не заметить того, что нарвался на проблемы. Нет?
Я такие "сюрпризы":
if(blablabla)
aha();
oxo();
находил и через несколько месяцев просле того, как они были закомичены
_FR>>Во-вторых, я всегда ставлю все кавыки по причине, отличной от возможных ошибок из-за забытых скобок (да, бывают такие причины), VD>Что за "кавыки"? И как они влияют на скобки? VD>И что за проблемы? Ну, и почему я их ни разу в жизни не видел? Может быть для этого нужно использовать старые компиляторы и писать в ноотпэде?
Ну вот абзацем выше пример привёл. Такие ошибки возникают, когда не всегда ставят операторные скобки.
_FR>>хотя несколько раз такие ошибки (с забытыми скобками и сдвинутым текстом) встречал у много более опытных и не менее, чем я, скурпулёзных программистов VD>А IDE ты ты не встречал? Они обычно умеют показывать где проблемы с незакрытыми скобками.
Не знаю, как IDE может здесь помочь: я такие ошибки встречал в коде, набранном в MSVS от шестёрки и до две тыщи восемь.
VD>И опять же причем тут не закрытые скобки и отсутствие скобок в тех местах где они не нужны?
Почему "закрытые"? Наверное, не "закрытые", а "забытые" — я это слово употребил, а "закрытые" вроде нет. Не редко, когда скобки ставят не всегда, при добавлении выражения забывают доставить скобки и тогда случаются ошибки (смотри пример в начале сообщения).
_FR>>В-третьих, неужели ты действительно не веришь, что таких ошибок не может быть? А раз они могут быть, то чем плох такой способ борьбы с ними?
VD>Я не считаю, что проблемы — это предмет веры. Они или есть, или нет. Если у меня есть выражение:
VD>when (a)
VD> b();
VD>то проблем от того что я не поставлю скобки не будет. А вот сами скобки будут совершенно лишними. Их наличие и код сделает длиннее, и введет заблуждение (если код не примитивный), так как я уже не смогу однозначно сказать один оператор в этом when или два, просто неграмотно отформатирован.
Я вижу проблемы в том, что для того, что бы добавить внутрь условия какой-то код, надо ещё добавить скобки вокруг. Мне кажется, это усложняет исправление, а, значит, и поддержку кода, ибо один из [основных!] критериев поддерживаемости — это простота и безопасность внесения изменений.
То есть проблема не в статике, не в написанном, а в динамике, в том, что такой код немножко сложнее поддерживать\исправлять\расшироять\дописывать и переписывать. Всё-таки ветвления и прочие циклы не редки, особенно в алгоритмических кусках. И мне кажется, что чем меньше мазков придётся нанести на картину для её исправления, тем качественнее картина написана.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А там можно получить неправильную программу просто вставив лишний пробел FR>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
Тоже, кстати, поинт хороший. Им стоило бы вообще запретить табы, как это сделали в F# #light.
А то с помощью смеси табов и пробелов — да еще в зависимости от настроек редактора — в питоне можно такое натворить, что все эти рассуждения о лишней паре {} покажутся детской забавой.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Честно говоря, что не нравится в синтаксисе Немерле так это именно имитация сишного синтаксиса зачастую с нарушением привычной семантики.
Про семантику ты явно преувеличиваешь.
ВВ>Например, взять операции инкремента/пост-инкремента
Что за связь?
ВВ> ( хотя это макросы, наверное? ).
Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?
Что до скобок в именно в операторе match, то у меня была идея сделать так чтобы фигурные скобки в match были не обязательными если все вхождения match-а (то что идет за =>) содержат ровно по одному выражению (не содержат точек с запятой или состоят из одного блока). Например:
def z = match (expr)
| x => x + y
| _ => f(expr);
или
def z = match (expr) | x => x + y | _ => f(expr);
ВВ>В Си-подобных языках скобочки всегда задают лексический скоп, но в случае с match-ем — это не так. Скоп задается на уровне каждого вхождения матча, а не всего матча в целом.
Почему же это не так? Скобки тоже задают лексический "скоп". Просто в нем нельзя объявлять переменные.
Ну, и нужно понимать, что язык все же гибридный, что дает ему не всегда следовать сишным догмам. Запомнить, что вхождение матча тоже создает скоп не так уж сложно. Зато это очень удобно. Скобки тут были бы совершенно лишними, по-моему.
ВВ>С практической т.з. это все фигня, но... гм... с эстетической...
Эстетическая точка зрения в коде — это что-то новое. Точнее она у каждого своя. Один не может терпеть лишних скобок, другой без них жить не может, третий считает мудаками тех кто ставит открывающую скобку на предыдущей строке, четвертый наоборот.
Я могу только утверждать две вещи:
1. Какой-то стиль нужен. И в одном проекте должен использоваться единый стиль. Следовательно о стиле в одном проекте нужно договариваться.
2. Я предпочитаю конкретный стиль и с большим неудовольствием перестраиваюсь на другой. Но понимаю, что не должно быть разного стиля в одном проекте и скрипя сердцем перестраиваюсь. Так я стал писать пробелы между именем операторов (таких как if, swith, match, ...) и открывающей скобкой. Ранее я это не делал. Между тем писать пробел перед именем функции я категорически не хочу, так как это ужасно ухудшает читаемость (начинают разделяться единые выражения, что плохо отражается на понимании кода).
Как стоит открывающая фигурная скобка мне не все равно. Я предпочитаю ставить ее на новой строке, так чтобы она была на том же уровне что закрывающая скобка того же уровня. Это удобнее при навигации по коду (люблю перпрыгивать по скобкам вперед-назад). Но в принципе спокойно читаю код и в других стилях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Например, взять операции инкремента/пост-инкремента VD>Что за связь?
Ну они выглядят как аналогичные операции в Си, однако "работают" не так, т.е. семантика другая. Честно, мне сложно представить, зачем кому-то в функциональном языке потребовались такие макросы
ВВ>> ( хотя это макросы, наверное? ).
VD>Ага, он.
ВВ>>Или те же фигурные скобочки:
ВВ>>
VD>Ты же вроде про круглые говорил. Или ты решил все же тему махнуть?
Ну раз вы начали тут про фигурные флеймить, то я-то чем хуже...
VD>Что до скобок в именно в операторе match, то у меня была идея сделать так чтобы фигурные скобки в match были не обязательными если все вхождения match-а (то что идет за =>) содержат ровно по одному выражению (не содержат точек с запятой или состоят из одного блока). Например: VD>
VD>def z = match (expr)
VD> | x => x + y
VD> | _ => f(expr);
VD>
VD>или VD>
VD>def z = match (expr) | x => x + y | _ => f(expr);
VD>
Мне лично понравился бы такой синтаксис:
match (expr)
| x => x + y
| _ => { expr1; expr2; }
Вроде как для образца _ у нас два выражения.
Я, видимо, что-то не понимаю в синтаксисе Немерле, но зачем в таком случае дополнительные фигурные скобки вокруг match, неясно.
Да, и раз уж речь зашла... Если было бы клево, если б сокращенный синтаксис для матча можно было бы использовать внутри любых функций, кол-во параметров которых больше нуля (а не только с одним параметром).
ВВ>>В Си-подобных языках скобочки всегда задают лексический скоп, но в случае с match-ем — это не так. Скоп задается на уровне каждого вхождения матча, а не всего матча в целом. VD>Почему же это не так? Скобки тоже задают лексический "скоп". Просто в нем нельзя объявлять переменные.
Ага, лексический скоп, в котором нельзя объявлять имена. Фишку понял
VD>Ну, и нужно понимать, что язык все же гибридный, что дает ему не всегда следовать сишным догмам. Запомнить, что вхождение матча тоже создает скоп не так уж сложно. Зато это очень удобно. Скобки тут были бы совершенно лишними, по-моему.
Для вхождения я никогда не предлагал скобки. В Си тоже скобки — не единственная конструкция которая задает скоп. for, например, тоже задает скоп, независимо от наличия или отсутствия скобок. Т.е. это-то ИМХО нормально.
ВВ>>С практической т.з. это все фигня, но... гм... с эстетической... VD>Эстетическая точка зрения в коде — это что-то новое. Точнее она у каждого своя. Один не может терпеть лишних скобок, другой без них жить не может, третий считает мудаками тех кто ставит открывающую скобку на предыдущей строке, четвертый наоборот.
Это все верно, но "истина где-то рядом". Если большей части людей что-то неудобно или непривычно, то возможно это действительно плохо.
Здравствуйте, _FRED_, Вы писали:
_FR>Я такие "сюрпризы": _FR>
_FR>if(blablabla)
_FR> aha();
_FR> oxo();
_FR>
_FR>находил и через несколько месяцев просле того, как они были закомичены
Не, ну, возможно есть хроники которые ошибки месяцами выявлюят. У меня в худшем случае на сложную ошибку уходит 2-3 дня. И это точно не ошибки из разряда плохое форматирование.
Ну, и подобных проблемы я не видел еще ни разу.
Код отформатированный небрежно я сразу же считаю не качественным и при его чтении я его сразу же форматирую.
Код может иметь любые соглашения, но единые для всего проекта (ну или хотя бы файла).
Если же в форматировании кода нет системы, то код сразу же нужно признавать некорректным и без дополнительной проверки (с одновременным форматированием) не рассматривать. Точнее производить его верификацию и отладку.
_FR>Ну вот абзацем выше пример привёл. Такие ошибки возникают, когда не всегда ставят операторные скобки.
Где там ошибка то? Там черным по белому написано что код писал мудак не знающий о том, что такое форматирование кода. Лучшее что можно сделать с таким кодом — автоматически его переформатировать. Да и после этого к такому коду нужно относительно с большим подозрением. Ведь ламерсово оно не останавливается на форматирования. Форматирование — это только проявление ламерства.
VD>>А IDE ты ты не встречал? Они обычно умеют показывать где проблемы с незакрытыми скобками.
_FR>Не знаю, как IDE может здесь помочь: я такие ошибки встречал в коде, набранном в MSVS от шестёрки и до две тыщи восемь.
Возьми интеграцию C# MS VS начиная с 2001 и тупо отформатируй код через меню Edit\Advanced\Format Document и ты увидишь все проблемы с форматированием и скобками. Почти уверен, что IDEA и Eclips имеют такие же средства. Это только в твоих любимых языках это может быть проблемой (так как отступы в них что-то значат).
В С-подобных языках отступы, как и прочее форматирование (за исключением препроцессора) практически ничего не значат и нужны только для улучшения чтения.
VD>>И опять же причем тут не закрытые скобки и отсутствие скобок в тех местах где они не нужны?
_FR>Почему "закрытые"? Наверное, не "закрытые", а "забытые" — я это слово употребил, а "закрытые" вроде нет.
Термин не мой. Да и по фигу.
_FR> Не редко, когда скобки ставят не всегда, при добавлении выражения забывают доставить скобки и тогда случаются ошибки (смотри пример в начале сообщения).
Это. На дворе 21 век. Причем уже второе десятилетие. Любая добротная IDE это умела еще 10 лет назад.
Я помню, что когда писал на QuickC (в 1994 году), то имел проблему из-за забытой скобки. Но это было!!! 15 лет назад! Тогда IDE были полным фуфлом. Но сейчас?!...
_FR>Я вижу проблемы в том, что для того, что бы добавить внутрь условия какой-то код, надо ещё добавить скобки вокруг.
То есть проблема в том, что код нужно вводить только тогда это нужно? Супер! Аргумент из серии фиг оспоришь .
Опять же заведи себе IDE. Там есть такие фичи как снипеты. Можно просто выделить кусок кода и окружить его скобками. Хотя я как-то легко справляюсь вручную.
_FR>Мне кажется, это усложняет исправление, а, значит, и поддержку кода, ибо один из [основных!] критериев поддерживаемости — это простота и безопасность внесения изменений.
Ага — кажется.
А вообще, ты очень счастливый человек если самое сложное что тебе приходится испрвлять — это скобки. Я вот обычно часами сижу за отладчиком пытаясь понять ошибку в логике программы, а потом трачу от несколькоих секунд до нескольких минут на исправление всего кода, а не каких то там скобочек. Скобочки на этом форе не видно в микроскоп.
Да что уж там?! Я на табличное форматирование кода трачу в 100 раз больше времени чем на вписывание пары скобок. Я пока тебе отвечал, несколько скобок налепил уж если на то пошло.
_FR>То есть проблема не в статике, не в написанном, а в динамике, в том, что такой код немножко сложнее поддерживать\исправлять\расшироять\дописывать и переписывать.
Поддерживать сложно плохо написанный, и особенно, плохо спроектированный код. А есть в нем лишние скобки или нет — это вообще не проблема.
Если люди настолько не квалифицированный, что их неумение/не желание форматировать код приходится отлавливать вставкой лишних лексем, то вы на верном пути в мир ужасного кода.
_FR>Всё-таки ветвления и прочие циклы не редки, особенно в алгоритмических кусках. И мне кажется, что чем меньше мазков придётся нанести на картину для её исправления, тем качественнее картина написана.
Дык меньше их будет если не ставит лишние лексемы. Потом апелляция к тому, что сложно писать или менять код — это вообще полны лам. Тяжелее всего читать код! Все остальное фигня! И если я вижу бессмысленные вложенные скобки да еще и многоуровневые, то я начинаю упускать суть кода.
Казалось бы, причем тут Немерле? Но чем больше я пишу на этом языке тем реже у меня остается "сишных" if-ов, то есть if которые не возвращают выражение. Они конечно есть, но чаще как раз использую именно аналог сишного тернарного оператора "condition ? trueExpr : falseExpr". При этом вопросов о том писать лишние скобки или не писать даже не стоит. Ведь идиотизм писать так:
def x = if (condition) { a } else { b };
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
