Размещение скобки влияет на удобочитаемость? [дубликат]

Раньше мы использовали первый стиль (стиль K&R), потому что экраны были меньше, и код часто печатался на бумаге, называемой бумагой.

В наши дни у нас большие screen и второй метод (стиль ANSI) упрощают проверку совпадения скобок.

См. ЗДЕСЬ и ЗДЕСЬ для получения дополнительной информации.

Первый меньше по количеству строк (возможно, именно поэтому в разработке -Java- книгах используется этот синтаксис)

Второй: ИМХО легче читать, как всегда имеют две выровненные скобки.

В любом случае обе из них широко используются, это вопрос ваших личных предпочтений.

Руководство по стилю Google C ++ предлагает

Тип возврата в той же строке, что и имя функции, параметры в той же строке, если они подходят.

Функции выглядят следующим образом:

 ReturnType ClassName :: FunctionName (Type par_name1, Type par_name2) {
 Сделай что-нибудь();
 ...
}

Рекомендации по стилю кодирования WebKit предлагают

Определения функций: поместите каждую фигурную скобку в отдельную строку.

Справа:

 int main ()
{
 ...
}

Неверно:

 int main () {
 ...
}

Они предлагают фигурные скобки на одной строке для всего остального.

Стандарты кодирования GNU предлагают

Важно поместить открывающую скобку, которая запускает тело функции C, в столбце один, чтобы они начали defun. Некоторые инструменты ищут в первом столбце открытые фигурные скобки, чтобы найти начало функций C. Эти инструменты не будут работать с кодом, не отформатированным таким образом.

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

Также важно, чтобы определения функций начинали имя функции в первом столбце. Это помогает людям искать определения функций, а также может помочь некоторым инструментам их распознать. concat (символ * s1, символ * s2) { ... }

или, если вы хотите использовать традиционный синтаксис C, отформатируйте определение следующим образом:

 static char *
concat (s1, s2) / * Здесь имя начинается с первого столбца * /
 char * s1, * s2;
{/ * Открывающая фигурная скобка в первом столбце здесь * /
 ...
}

Как видите, у каждого свое мнение. Лично я предпочитаю фигурные скобки в стиле Perl-on-same-line-except-for- else , но пока все, кто работает над кодом, могут сотрудничать, это действительно не имеет значения.

Я использую оператор if как аргумент в пользу этой очень эмоциональной темы.

if (cond) {
   //code
}

просто спрашивая, как выглядит оператор else? Логическое продолжение вышесказанного: -

if (cond) {
   //code   
} else {
   //more code
}

Это можно читать? Я так не думаю, и это тоже просто уродливо.

Больше строк! = Менее читабельно. Поэтому я бы выбрал второй вариант.

С первым вариантом количество строк кода будет значительно меньше. :)

Лично я считаю, что второй вариант более читабелен (выровненные фигурные скобки).

Команде всегда проще всего использовать значения по умолчанию, и, поскольку Visual Studio и я согласны с этим, это мой аргумент. ; -)