Есть ли какая-то причина, по которой блоки c всегда имеют {сразу после ^, а не на новой строке? - PullRequest
2 голосов
/ 26 января 2011

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

int aBoringCFunction()
{
    ...

Apple использовала этот стиль, но сменила { на той же строке, что и функция.При использовании блоков код Apple всегда имеет { непосредственно после ^:

dispatch_async(dispatch_get_main_queue(), ^{
                   ...

. Есть ли какая-то причина, по которой использование моего стиля с блоками было бы проблематичным?Например:

dispatch_async(dispatch_get_main_queue(), ^
{
    ...

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

Уточнение

Этот вопрос касается Блокирует расширение языка C .Это не общий вопрос о брекетах.Вопрос в том, имеет ли расширение Blocks какие-либо последствия для стиля кода.

Ответы [ 6 ]

2 голосов
/ 26 января 2011

Оба стиля совершенно верны; это вопрос стиля и предпочтений. Единственный способ, которым это будет проблемным , может заключаться в том, что вы можете ожидать соблюдения соглашения Apple в зависимости от того, для кого предназначен ваш код. Следовательно, возможно, вам придется вернуться и немного изменить форматирование, прежде чем ваша работа будет принята.

1 голос
/ 26 января 2011

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

Наличие фигурной скобки на одной линии - это стиль «K & R», стиль, который использовался в Си с самого начала. Иметь его на отдельной строке, пожалуй, самое распространенное в наши дни.

Но нет никаких доказательств того, что один из двух стилей лучше, чем другой, для ясности. Если кто-то спорит из-за одного стиля над другим, попросите научного исследования по этому вопросу. Я еще не видел таких.

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

1 голос
/ 26 января 2011

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

0 голосов
/ 26 января 2011

У разных людей разные вкусы кодирования. В целом, большие проекты поставляются с рекомендациями по стилю кодирования. Например, KDE нравится так же, как и вы: {на следующей строке. Им также нравятся пробелы в операторах if:

if (this_var> 42)

Что лично я не вижу необходимости. У меня был сотрудник, который любил иметь 5 пустых строк после каждой функции. Для него было важно визуальное разделение. Для меня, однако, мне нравится выводить на экран как можно больше.

В этом нет ничего плохого. Есть только пробел.

Мой самый любимый коммит-лог, который я когда-либо писал для проекта, после того, как мы договорились о едином стиле (который длится 10 лет):

2002-04-20 00:07  hardaker

   * everything:

   White space, oh glorious white space.
   How great our though?
   The code is fine.
   We agree on functionality easily.
   What really troubles us?
   Something we can't see.
   Something between the code.
   We bow down to your magnificence,
   For you are everywhere,
   Between everything.
   Pretty nothingness you are.
0 голосов
/ 26 января 2011

Традиционно программисты старались использовать как можно меньше строк, потому что вы можете видеть только 24 на терминалах, которые использовались.Помещение {в свою очередь просто тратит впустую пространство экрана.

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

0 голосов
/ 26 января 2011

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

...