Привет!

Как-то со знакомым возник спор на тему того, какой из следующих кусков кода является наиболее читаемым:

// 1

void foo
try
{
    bar();
    baz();
}
catch (const SomeException& ex)
{
    // ...
}

// 2

void foo
{
    try
    {
        bar();
        baz();
    }
    catch (const SomeException& ex)
    {
        // ...
    }
}

Оговорки следующие:

• Обе функции, вызываемые внутри foo, могут выбрасывать исключения только одного типа SomeException.
  
• Кроме вызовов функций, которые выбрасывают SomeException, никаких других действий в foo не выполняется. Следовательно, обрабатывать исключения более локально не требуется.

Я выступал за первый вариант, т.к. в данном случае мы избавляемся от лишней вложенности, которая здесь не нужна. Минусом такого подхода является, конечно, то, что подобная конструкция встречается не так уж и часто (да и вообще была придумана лишь ради того, чтобы использовать её в списке инициализации конструкторов), в связи с чем некоторые программисты могут застрять на пару минут, перечитывая данный кусок кода.

Надо скобкой на строку заголовка класть, так вкуснее будет:

// 3

void foo {
    try {
        bar ();
        baz ();
    } catch (const SomeException& ex) {
        // ...
    }
}

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

FH>Как-то со знакомым возник спор на тему того, какой из следующих кусков кода является наиболее читаемым:

монописуально же

Оба решения имеют плюсы и минусы.
Нужен руководитель, который примет окончательное решение,
а так можно долго фигнёй страдать

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

FH>Как-то со знакомым возник спор на тему того, какой из следующих кусков кода является наиболее читаемым:

Если речь идёт о личных предпочтениях — спорить бессмысленно. Как по мне, ваши доводы за первый вариант — это скорее агитация за второй

Если о стиле кодирования в команде, то подобные моменты имеет смысл определять политикой только если они проверяются автоматически при коммите. Идеальный вариант — код автоматически форматируется при сохранении. Иначе вы потеряете больше времени от соблюдения политики, чем сэкономите на чтении одинаково оформленного кода.

Только второй.

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

FH>Я выступал за первый вариант, т.к. в данном случае мы избавляемся от лишней вложенности, которая здесь не нужна. Минусом такого подхода является, конечно, то, что подобная конструкция встречается не так уж и часто (да и вообще была придумана лишь ради того, чтобы использовать её в списке инициализации конструкторов), в связи с чем некоторые программисты могут застрять на пару минут, перечитывая данный кусок кода.

Только второй вариант. Не хватает ещё застревать на пару минут при чтении тривиальнейшего куска кода.

2ой вариант, ибо код переносимие на другие языки программирования.

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

o> Надо скобкой на строку заголовка класть, так вкуснее будет:
o>

o> void foo {
o> }
o>

Egyptian brackets? Нет уж, увольте.

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

.>Egyptian brackets? Нет уж, увольте.
Почему?

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

.>>Egyptian brackets? Нет уж, увольте.
F> Почему?

Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.

Знаю оба варианта но лично только за второй. В этом и смысле софтваре инжениринга — не поддаваться на провокации а сделать код простым и понятным для остальный программистах. И речь не только об конкретно одной этой конструкции а вообще.

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

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

.>>>Egyptian brackets? Нет уж, увольте.
F>> Почему?

BFE>Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.

Кому должны?

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

BFE>>Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.
G>Кому должны?
Друг-другу.

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

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

BFE>>>Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.
G>>Кому должны?
F> Друг-другу.

Хватит с них того, что они находятся на одной странице!

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

.>>>>Egyptian brackets? Нет уж, увольте.
F>>> Почему?
BFE>>Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.
G>Кому должны?
Читателю.

Здравствуйте, fddima, Вы писали:
F>Здравствуйте, ., Вы писали:
.>>Egyptian brackets? Нет уж, увольте.
F> Почему?
научиться глазами ловить можно оба варианта
против них есть два аргумента
первый — неудобно комментить условия для отладке
второй я забыл

Здравствуйте, FrozenHeart, Вы писали:
FH>Я выступал за первый вариант, т.к. в данном случае мы избавляемся от лишней вложенности, которая здесь не нужна. Минусом такого подхода является, конечно, то, что подобная конструкция встречается не так уж и часто (да и вообще была придумана лишь ради того, чтобы использовать её в списке инициализации конструкторов), в связи с чем некоторые программисты могут застрять на пару минут, перечитывая данный кусок кода.
логично, но я бы лично подвис над первым вариантом
а нужно следовать принципу минимальной неожиданности, посему вариант 2

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

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

.>>>>>Egyptian brackets? Нет уж, увольте.
F>>>> Почему?
BFE>>>Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.
G>>Кому должны?
BFE>Читателю.

Хотите ощутить себя читателем противоположного стиля? — Сделайте еще по паре пустых строк до и после этой скобочки. Как оно?

ИМХО лишние пустые строки — точно такой же мусор на экране как и все другое...

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

G> Хотите ощутить себя читателем противоположного стиля? — Сделайте еще по паре пустых строк до и после этой скобочки. Как оно?
А зачем? Почему пару, а не четырнадцать? Это всё алогично. Как и алогично открывающую скобку писать как-то по другому, чем закрывающую.

G> ИМХО лишние пустые строки — точно такой же мусор на экране как и все другое...
Будьте последовательны, не ставьте и перед закрывающей, мусора ещё меньше будет. И после тоже не ставьте.

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

.>>>>>>Egyptian brackets? Нет уж, увольте.
F>>>>> Почему?
BFE>>>>Открывающая и закрывающая скобки должны находиться либо на одной строке, либо в одном столбце. Для удобства чтения.
G>>>Кому должны?
BFE>>Читателю.

G>Хотите ощутить себя читателем противоположного стиля? — Сделайте еще по паре пустых строк до и после этой скобочки. Как оно?
G>ИМХО лишние пустые строки — точно такой же мусор на экране как и все другое...

Пустые строки на экране совершенно не напрягают. Собственно, я и сейчас из-за "корпоративных" правил иногда пишу так:

    if ( a < b ) {

        c = b - a;
    }
    ....

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

G>> ИМХО лишние пустые строки — точно такой же мусор на экране как и все другое...
.>Будьте последовательны, не ставьте и перед закрывающей, мусора ещё меньше будет. И после тоже не ставьте.

Закрывающая скобка показывает конец блока. Открывающая для начала совершенно необязательна, т.к. в 99% случаев начало блока видно по соответствующему ключевому слову.

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

G> .>Будьте последовательны, не ставьте и перед закрывающей, мусора ещё меньше будет. И после тоже не ставьте.
G> Закрывающая скобка показывает конец блока. Открывающая для начала совершенно необязательна, т.к. в 99% случаев начало блока видно по соответствующему ключевому слову.
Зачем нужны правила работающие в 99% случаев, если есть правила работающие в 100%?
Блок есть блок, а ключевое слово — ключевое слово. Непонятно, почему именно блоки с ключевыми словами какие-то особенные.
Скажем, вот такое непонятно как правильно форматировать c egyptian brackets:

String[][] a =
{
    {
        "aaaaaaaaaaaaaaa",
        "bbbbbbbbbbbbbbbbbbbbb"
    },
    {
        "ccccccccccccccccc",
        "ddddddddddddddddddddddddddd",
        "eee"
    }
};

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

.>Зачем нужны правила работающие в 99% случаев, если есть правила работающие в 100%?
Да-да, пустая строка при открывающей скобке — 100% лишняя.

.>Блок есть блок, а ключевое слово — ключевое слово. Непонятно, почему именно блоки с ключевыми словами какие-то особенные.
Они не особенные, просто блок прекрасно видно — начало и конец. Перенос скобки детект блока не облегчает, а пространство жрет.

.>Скажем, вот такое непонятно как правильно форматировать c egyptian brackets:
.>

.>String[][] a =
.>{
.>    {
.>        "aaaaaaaaaaaaaaa",
.>        "bbbbbbbbbbbbbbbbbbbbb"
.>    },
.>    {
.>        "ccccccccccccccccc",
.>        "ddddddddddddddddddddddddddd",
.>        "eee"
.>    }
.>};
.>

Не вижу проблемы, за отсутствием ключевого слова и такой подход прокатит (для внутренних блоков).