Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, snaphold, Вы писали:
S>>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?
G>Чем меньше обязательных скобок, тем лучше. Чем больше конструкций языка является выражениями, тем лучше.
а как быть с кодстайлом? у нас в код ревью правило if/for/функция на бэке в скобках. вот пришел толковый парень и стал продвигать это правило.
идея хорошая но писать по новым правилам непонятно потом как ревью делать когда есть с {} и без
Здравствуйте, snaphold, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, snaphold, Вы писали:
S>>>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?
G>>Чем меньше обязательных скобок, тем лучше. Чем больше конструкций языка является выражениями, тем лучше.
S>а как быть с кодстайлом?
Придумать новый
S> у нас в код ревью правило if/for/функция на бэке в скобках.
ИМХО if и for лучше в скобках, так как возможны неявные ошибки. А функции не обязательно, так как лямбда-синтаксис.
Здравствуйте, snaphold, Вы писали:
S>а как быть с кодстайлом? у нас в код ревью правило if/for/функция на бэке в скобках. вот пришел толковый парень и стал продвигать это правило. S>идея хорошая но писать по новым правилам непонятно потом как ревью делать когда есть с {} и без
мне вот кажется, что такие хотелки не должны быть в code style. Пробелы/табы, где открывающая скобка, именование переменных и функций. Это максимум. В остальном надо давать свободу программисту
S>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?
Go зафиксировал единый стиль скобок по всему миру...
И в этом есть смысл.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, snaphold, Вы писали:
S>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?
Не про шарп, но в {} обычно пишут statements (грязные функции, выполняющие какую-то работу), а без скобок — expressions (чистые функции, возвращающие результат и не меняющие мутабельное состояние)
Здравствуйте, snaphold, Вы писали:
S>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?
Не люблю эту фичу. При чтении кода сходу не понятно, что это метод. Больше похоже на свойство. Приходится затрачивать несколько дополнительных тиков на парсинг.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
S>>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ? LVV>Go зафиксировал единый стиль скобок по всему миру... LVV>И в этом есть смысл.
Что касается if и подобных блоков — считаю, что тут правило простое: если условие и тело помещаются в одну строку (например `if (x < 0) return null`), то фигурные скобки нужно опускать. Если в одну строку не помешаются и нужен перенос — тогда фигурные скобки нужны.
Что касается остальных инструкций — тут надо смотреть по каждой отдельно. В целом можно применять это же правило.
LVV>>Go зафиксировал единый стиль скобок по всему миру... LVV>>И в этом есть смысл. M>Надеюсь, карнигановский?
Понятия не имею. M>ЗЫ А питон зафиксировал отступы. И чо?
Это гораздо хуже. Наличие скобок, пусть даже и зафиксированных — гораздо лучше.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, snaphold, Вы писали:
S>Когда-то давно я помню из с++ взял привычку каждую функцию и каждый if\for оборачивать в {}
S>потом из жаваскрипта стал перенимать что часто это делается без скобок {}
Есть примеры где так пишут ?
Я встречаю только обязательные скобки в JS.
S>но сейчас в си шарпе вижу уже уход от {}
S>
Здравствуйте, snaphold, Вы писали:
G>>Чем меньше обязательных скобок, тем лучше. Чем больше конструкций языка является выражениями, тем лучше.
S>а как быть с кодстайлом? у нас в код ревью правило if/for/функция на бэке в скобках
Он написал: "обязательных", а правило код ревью это про опциональные.
Здравствуйте, scf, Вы писали:
S>>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?
scf>Не про шарп, но в {} обычно пишут statements (грязные функции, выполняющие какую-то работу), а без скобок — expressions (чистые функции, возвращающие результат и не меняющие мутабельное состояние)
Про то, что все уходят от statements к expressions и это удобно, согласен. А вот требование чистоты откуда взялось? Разве главное не возможность сохранить через выведение типов и возможность передать в функцию?
Здравствуйте, Alekzander, Вы писали:
A>Про то, что все уходят от statements к expressions и это удобно, согласен. А вот требование чистоты откуда взялось? Разве главное не возможность сохранить через выведение типов и возможность передать в функцию?
Явное разделение чистых и грязных функций в коде повышает его читабельность. y = a(x) + b(x) выглядит простым и понятным, но если функции при каждом вызове c одним и тем же аргументом могут возвращать разные данные, то этот код автоматически становится сложным.
Здравствуйте, scf, Вы писали:
A>>Про то, что все уходят от statements к expressions и это удобно, согласен. А вот требование чистоты откуда взялось? Разве главное не возможность сохранить через выведение типов и возможность передать в функцию?
scf>Явное разделение чистых и грязных функций в коде повышает его читабельность. y = a(x) + b(x) выглядит простым и понятным, но если функции при каждом вызове c одним и тем же аргументом могут возвращать разные данные, то этот код автоматически становится сложным.
Вопрос был не про преимущества чистых функций, а про то, на каком основании чистота объединена с заменой стейтментов выражениями. Это два разных тренда, ИМХО.
многие вещи, не только скобки кредитуют возможное будущее увеличение сложности. разделение на слои/абстракции, репозитории, модели/карго обьекты и так далее. мы уже делаем это часто и много иногда во благо а иногда просто так. почему всех бесят какие то несчастные пара скобок?