Если вы разбиваете длинные строки кода, как сделать отступ в следующей строке? - PullRequest
38 голосов
/ 31 марта 2009

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

Вы можете сделать отступ одинаковым:

very long
statement;
other statement;

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

very long
   statement;
other statement;

Это облегчает, но может случиться так, что длинная строка - это начало вложенного блока, который вы хотите сделать отступ, например:

if ((long test 1) &&
   (long test 2) &&
   (long test 3)) {
   code executed if true;
}

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

Какую возможность вы предпочитаете? У вас есть другие идеи, чтобы решить эту проблему? Можете ли вы поддержать ваши предпочтения с хорошим обоснованием?

Ответы [ 15 ]

41 голосов
/ 31 марта 2009

Мне нравятся фигурные скобки на их собственной строке, потому что я прекрасно понимаю, что условие и внутренний блок проще видеть как один элемент (если вы понимаете, о чем я):

if ((long test 1)
    && (long test 2)
    && (long test 3)) 
{
    code executed if true;
}

и мне нравится начинать дополнительные условные строки с того, что является условием, потому что я считаю, что условие "присоединения" очень важно, и оно имеет тенденцию игнорироваться в конце предыдущей строки.

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

Я стараюсь структурировать вещи так, чтобы я мог легко "сканировать" на предмет "вещи":)

30 голосов
/ 31 марта 2009

Вам следует попытаться запретить написание строк длиннее 80 символов , а не разбивать их:

  • Старайтесь минимизировать отступы путем преобразования условий и инкапсуляции кода.

Линус Торвальдс: если вам нужно более 3 уровней отступ, ты все равно облажался,
и должен исправить вашу программу.

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

bool encapsulatedLongCondition() // Add some parameters
{
  if (!condition1)
    return false;

  if (!condition2)
    return false;

  // ... (Other conditions)

  return true;
}    

if (encapsulatedLongCondition())
{
  // ... (Call some methods, try not to introduce deeper if/loop levels!)
}

Упрощение вашего состояния с помощью булевой алгебры и попытка инвертировать условие и возвращаемое значение могут очень помочь. : -)

См. Также: Можете ли вы упростить этот алгоритм? Смотрите также 2: Refactor for C # может помочь вам в этом. ; -) * 1 021 *

  • Используйте определения типов и старайтесь избегать длинных имен

Простой пример, представьте, как долго будет использоваться Days без typedef с длинными именами в другом контейнере.

struct Day
{
  // Some data
};
struct Event
{
  // Some data
};
typedef list<Event> Events;
typedef map<Day, Event> Days;
// Some other container that would else be long...
  • ... (Вы должны попытаться проанализировать, почему ваша строка длинная и найти решение для нее)

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

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

void longFunctionName(ParameterType1 parameter1, ParameterType2 parameter2,
                      ParameterType3 parameter3, ParameterType4 parameter4)  
8 голосов
/ 17 ноября 2009

В общем делаю:

if (condition) {
     something;
}

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

if (
    (long test 1) &&
    (long test 2) &&
    (long test 3)
) {
    code executed if true;
}

Ключевые отличия от ответа Робби:

  1. Операторы в конце каждой строки вместо начала последующих строк, чтобы очень четко визуально указать, что строка является неполной
  2. Разрыв строки на первой строке перед условным элементом - это помогает поддерживать согласованность «формы» кода.
  3. Закрывающая часть без отступа.

Это визуально приводит к тому, что списки параметров / условных списков выглядят как кодовые блоки (но с паренами вместо фигурных скобок. Я считаю, что симметрия приятна. Она также позволяет избежать использования открывающих фигурных скобок на линии (что я думаю) выглядит ужасно).

7 голосов
/ 31 марта 2009

У меня есть два простых правила:

  1. Блок операторов: один отступ;
  2. Продолжение строки: два отступа или круглые скобки, независимо от того, что имеет дальнейший отступ.

Итак, в случае if:

if ((long test 1) &&
        (long test 2) &&
        (long test 3)) {
    code executed if true;
}
4 голосов
/ 31 марта 2009

Я на стороне, "Не борись с IDE."

Однако моя IDE (Eclipse, Visual Studio) хочет разбивать строки так, как они ломаются.

Это может означать несоответствия между языками, что нормально.

3 голосов
/ 31 марта 2009

У меня есть небольшое отклонение от того, что уже написано здесь:

if ((long test 1) &&
    (long test 2) &&
    (long test 3)) 
{
    code executed if true;
}

Мне нравится, когда мои логические операторы находятся в конце строки.

Длинные имена методов или методы с большим количеством параметров выглядят так:

reallyLongMethodName (paramA,
                      paramB,
                      paramC);

с битами, выровненными с именем параметра выше; не скобка ...

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

for(int i = 0; i < MAX; i++)
{
    if(!isPrime(i)) // predefined prime finding func
        continue;

    //now we have only prime values of i
}
2 голосов
/ 31 марта 2009

Всегда отступ, но если операторы особые; Мне нравится выстраивать тесты, и я помещаю дополнительные операторы && слева:

if (  (long test 1)
   && (long test 2)
   && (long test 3)) 
{
    code executed if true;
}

Вытягивание && влево для выравнивания с if также возможно, но мне труднее читать эту альтернативу.

2 голосов
/ 31 марта 2009

Я задавал похожий вопрос в прошлом:

Где обернуть строку кода, особенно длинные списки аргументов?

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

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

2 голосов
/ 31 марта 2009

Я держу выражения в скобках на уровне их открытия:

if ((long test 1) &&
    (long test 2) &&
    (long test 3)) {
  code executed if true;
}

Это делает очевидным, на каком уровне находится каждое выражение.

1 голос
/ 31 марта 2009

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

1) это сложно в этой ситуации, потому что есть много разных возможностей для ломаных

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

...