Когда-то давно я помню из с++ взял привычку каждую функцию и каждый if\for оборачивать в {}

потом из жаваскрипта стал перенимать что часто это делается без скобок {}
но сейчас в си шарпе вижу уже уход от {}

 private static HashSet<(string, string)> GetKeys() => keys.Where();

ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?

Здравствуйте, snaphold, Вы писали:

S>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?

Чем меньше обязательных скобок, тем лучше. Чем больше конструкций языка является выражениями, тем лучше.

Здравствуйте, 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>

S> private static HashSet<(string, string)> GetKeys() => keys.Where();
S>

S>ваши мысли насчет {} в том же шарпе. пишем в новой парадигме "меньше писать чтобы" ?

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

public HashSet<string> GetKeys() => _keys ??= new();

public HashSet<string> GetValues() => _keys ?? throw new InvalidOperationException("No data");

public GetLogType() => _logType switch
{
 Information => 0,
 Warning => 1,
 Critical => 2,
 _ => -1
};

Здравствуйте, 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 одним и тем же аргументом могут возвращать разные данные, то этот код автоматически становится сложным.

Вопрос был не про преимущества чистых функций, а про то, на каком основании чистота объединена с заменой стейтментов выражениями. Это два разных тренда, ИМХО.

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

scf>если функции при каждом вызове c одним и тем же аргументом могут возвращать разные данные, то этот код автоматически становится сложным.

нафиг такие функции, это первая задачa рефакторинга. понятно, что языковые функциии типа замыканий активнo провоцируют такие проблемы, но.