Причина размещения типа функции и имени метода на разных строках в C

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

void foo() {
}

должно быть это

void
foo() {
}

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

Интересно, есть ли какая-либо причина, кроме личных предпочтений, почему люди используют второй стиль?

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

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

Если у компании установлен стиль, у них также может быть документ по стандартам кодирования. Спроси об этом. Это может объяснить причину (ы) такого выбора, и наличие копии поможет вам избежать подобных проблем в будущих обзорах.

Это практически единственное правило форматирования кода, которое я обнаружил, на самом деле оказывает заметное влияние на удобочитаемость и практически не требует усилий (при условии, что ваш редактор кода не начинает с вами бороться за это).

Это хороший дизайн языка программирования, чтобы имена появлялись в согласованной позиции в объявлениях / определениях. Обоснование простое: у вас есть хороший визуальный якорь (фигурная скобка или просто висячий отступ), который вы можете использовать, чтобы сразу найти начало имени. Вам не нужно фактически анализировать язык при сканировании файла, чтобы найти имя.

Это то же самое, что и при форматировании документа: когда вы начинаете новый раздел, вы помещаете имя впереди жирным шрифтом - часто в отдельной строке - где-то не похороненным, недифференцированным, в длинном предложении.

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

double dot(x, y);

Все еще довольно легко усваивается.

C ++ сделал это немного хуже. Он перемещал спецификации типов аргументов в сигнатуры, делая подписи длиннее. Этот синтаксис был позже принят во время стандартизации C.

static struct origin *find_origin(struct scoreboard *sb,
                  struct commit *parent,
                  struct origin *origin)

менее усваивается, но не так уж плохо. (Выдержка из Git)

Теперь рассмотрим современные практики программирования с длинными описательными именами и параметризованными типами и посмотрим, как этот выбор стал катастрофическим. Пример из заголовка Boost:

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

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

C, C ++ и их производные, Java и C #, кажутся исключениями из наличия читаемых объявлений / определений. Их популярные предшественники и коллеги (Fortran, ALGOL, Pascal) помещали имена перед типами результатов, и, к счастью, многие из их преемников (Go, Scala, TypeScript и Swift и многие другие) также выбрали более читаемые синтаксисы.

Впервые я познакомился с этим стилем примерно на 19-м году, работая с C & C ++. Был в значительной степени озадачен тем, как кто-то может изобрести эту злую вещь.

Единственный (потенциально) положительный момент, который я смог найти, это то, что вы можете найти определение функции, используя grep ^ FuncName. Может быть значимым фактором десятилетие назад в некоторых реальных сообществах, ненавидящих инструменты ... В том месте, где я видел, оно применялось к функциям C ++ и членов класса, которые убивают даже этот атрибут.

Угадай мое мнение :)