Как и где повредить длинные строки кода? [дубликат]

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

Когда я говорю о семантическом блоке, я имею в виду, что обычно в длинном высказывании есть какая-то схема, позволяющая разделить его на несколько процессов. Они могут быть отдельными строками, но иногда они достаточно тривиальны, чтобы разбить их на строки, особенно если вы используете объект цепочки.

Это личное предпочтение только, поскольку вопрос является субъективным, но я стараюсь следовать этим рекомендациям.

• Ограничьте код до 79 символов, где это возможно (это просто для того, чтобы он хорошо распечатывался с достаточно большим размером шрифта, чтобы мои стареющие глаза могли его прочитать). Обычно я сначала разбиваю их где-то в диапазоне 60, чтобы неизбежное редактирование строк для исправления проблем не означало, что мне нужно много переформатировать: -)

• Разбейте строку как можно выше в иерархии . Под этим я подразумеваю x = 1 * 2 + 3 * (4 + 5); будет разбит на первом + , а не где-либо еще. Это потому, что «элементами» самого высокого уровня являются x , 1 * 2 и 3 * (4 + 5) .

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

Что-то вроде:

x = 1 * 2 +
    3 * (4 + 5);

или:

if (1 * 2 =
    3 * (4 + 5))
{
    doSomething();
}

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

if (1 * 2 = 3 * (4 + 5)) {
    doSomething();
}

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

if (1 * 2 =
    3 * (4 + 5)) {
    doSomething();
}

, что мне не нравится.

Что касается струн, если они длиннее, чем я предпочитаю, я стараюсь их разбивать. C и его собратья упрощают эту задачу, поскольку компилятор обрабатывает "abc" "def" точно так же, как "abcdef" . Даже если есть влияние времени выполнения (например, конкатенация строк), я разбиваю их, но все равно постараюсь минимизировать такие воздействия.

Пара вариантов:

1. Установите стандарт с коллегами.
2. Ширина печати.
3. Ширина экрана.

-Ура.

С исторической точки зрения, это была старая ширина 80 столбцов из-за размера экрана. Однако, поскольку это не всегда так, я думаю, что строго следовать этому правилу не обязательно.

Однако, если подумать, на самом деле вы не хотите прокручивать экран, чтобы на самом деле прочитать весь бит кода. Разбить его - определенно хорошая идея, поэтому использование 80 столбцов облегчит чтение, если вы перешли с широкого экрана на ноутбук.

Вот как я разделил материал:

1) После оператора

if(longVariableName || someOtherVariable ||  
   nextVariable)  
{
   //Some code here.
}

Когда вы читаете код, разбиение его после оператора означает, что последняя операция (|| в моем примере) была в ваша голова, когда вы начали читать очередного оператора. Облегчает чтение, понимание и понимание.

Поскольку современные IDE поддерживают горизонтальную прокрутку, меня не очень волнует длина строки как таковая (если только моя команда этого не делает); только то, насколько она проста для понимания. Но это редко имеет значение, потому что я разбиваю вещи на строки или методы, чтобы облегчить их понимание, поэтому длина строки автоматически остается небольшой.

Это зависит от выбранной вами среды: вашего языка, ваших стандартных IDE, ваших коллег и того, что по своей сути выглядит красиво и легко для вас .

Вы не упомянули, за кем из них вы хотите следовать. Если вам когда-либо приходилось ожидать редактирования этого кода в окне терминала, вы можете начать с классического режима ожидания: 80 символов - больше, и некоторые терминалы и редакторы CLI болезненно ломаются или переносятся. Многие IDE предоставляют визуальную подсказку на отметке 80-го столбца именно по этой причине. Если вы можете разумно ожидать, что каждый, кто просматривает код, будет использовать полнофункциональные IDE (например, XCode, Eclipse и MS Visual Studio), то это не является для вас требованием.

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

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

«Предложение» здесь - это выражение, которое можно заключить в круглые скобки. Математические составные выражения разбиваются на оператора, и оператор в первую очередь в последующих строках. Когда мы говорим о длинном логическом блоке, например, в операторе if или в цикле while / for, применяется то же самое: я разбиваю statemnt с отступом следующих строк и первым оператором.

Если вы работаете над OSX с Objective-C, XCode вам поможет. Он автоматически сделает отступ в последующих строках таким образом, чтобы символы ':' были выровнены равномерно. Это дает потенциально легкий для чтения вызов метода.

По сути, вам следует попробовать более длинные строки для себя и решить, в какой момент что-то становится трудным для понимания. С письменным текстом (комментариями или художественной литературой) я обнаружил, что чрезмерно широкие столбцы кажутся беглыми предложениями и позволяют легко потерять свое место. Когда длина строк в коде превышает 100 символов, это обычно означает, что есть много предложений, и если вам нужно прокручивать вправо / влево для чтения, то легко потерять поток того, что пытается сделать ваш код.Наконец, когда у вас примерно 100 символов в строке, вы можете открыть два окна кода бок о бок для сравнения / контраста / контекстной информации ... и т. Д. Длинные строки делают это непрактичным.

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