Если вы сломаете длинные строки кода, как вы отступаете от материала на следующей строке?

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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 для С# имеет возможность помочь вам в этом.; -)

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

Простой пример, представьте, как долго он будет использовать Дни без 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)  

Ответ 3

В общем, я:

if (condition) {
     something;
}

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

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

Основные отличия от ответа rbobby:

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

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

Ответ 4

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

• Блок Statement: один отступ;
• Продолжение строки: выровнены две выемки или скобки, что дальше отступом.

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

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

Ответ 5

Я сторонник, "Не сражайтесь с IDE".

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

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

Ответ 6

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

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

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

Ответ 7

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

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
}

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

Я задал аналогичный вопрос в прошлом:

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

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

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

Ответ 11

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

• разумно
• вы применяете одно и то же соглашение во всем своем коде.

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

Ответ 12

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

Обоснование, как насчет цитата Линуса Торвальдса?:)

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

Обычно я следую конгломерату стиль кодирования Google С++ (вы тоже можете адаптировать это к Java) и этот стиль кода С++.

Ответ 13

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

a 
= b
= c
= d
= e
= f
= 0;

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

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

reallyLongMethodName (paramA,paramB,paramC);

не будет отформатирован как

reallyLongMethodName (paramA,
    paramB,
    paramC);

но в итоге получится больше

reallyLongMethodName (paramA,
                    paramB,
                    paramC);

со всеми параметрами, выравнивающимися с открывающей скобкой.

Ибо, если и когда я буду делать что-то вроде

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

Ответ 14

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

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

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