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

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

На самом деле, я бы сказал, что я структурирую свой код так, как я пишу: я делаю абзацы не длиннее нескольких строк (определенно короче 10) и пытаюсь сделать каждый абзац автономным.

Например:

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

В целом, у меня редко бывает более 4/5 строк, сгруппированных вместе, что означает очень разреженный код.

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

Например:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

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

Итак, как вы на самом деле используете (или нет) пустые строки в коде?

Всегда

Пробелы имеют решающее значение для очистки читаемого кода. Пустая строка (или две) помогают визуально выделить логические блоки кода.

Например, из главы « Сложный код» Стива Макконнелла, второе издание, посвященной макету и стилю:

Субъекты набрали от 20 до 30 процентов выше в тесте на понимание, когда программы имели схему отступов от двух до четырех пробелов, чем когда программы вообще не имели отступов.Это же исследование показало, что важно не подчеркивать и не подчеркивать логическую структуру программы. Самые низкие баллы понимания были достигнуты по программам, которые не имеют отступов вообще. Второе самое низкое было достигнуто на программах, которые использовали отступ с шестью пробелами. Исследование пришло к выводу, что отступ в два-четыре пространства был оптимальным. Интересно, что многие участники эксперимента чувствовали, что отступ в шесть мест проще в использовании, чем более мелкие, хотя их оценки были ниже. Это, вероятно, потому, что шесть пробелов выглядят приятными. Но независимо от того, как красиво это выглядит, отступ с шестью пробелами оказывается менее читабельным. Это пример столкновения между эстетической привлекательностью и читабельностью.

Да для наглядности.

Так же, как я сделал в этом ответе.

Я делаю, но я удостоверяюсь, что документирую это

(This line intentionally left blank.)

на линии

Да, но я не злоупотребляю этим.

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

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

То же самое неправильное использование горизонтальных пробелов может быть применено к вертикальным пробелам. Как и любой инструмент, используйте его с умом.

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

Читаемость очень важна, когда вы возвращаетесь в проект после длительного периода времени, и я слышал поговорку: «Всегда пишите код, если следующий парень, который читает его, это психопат, который знает ваше местоположение».

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

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

• в классе я сгруппирую методы, которые идут вместе, отделяя их пустой строкой от следующей группы.

Поскольку у вас есть несколько связанных членов, они являются кандидатами в новый класс.

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

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

• в методе я делаю один абзац за шаг процесса

Почему бы не сделать один метод для каждого «абзаца»?

Если у вас в классе есть куча методов, см. Мою заметку выше о извлечении нового класса.

Да. Это облегчает визуальное сканирование файла. Помимо всего прочего, он проясняет, с какой строкой идет комментарий.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

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

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

Большая часть этого не страшно спорным; что может последовать Я отмечаю, что обозначение K & R с открытыми скобками в конце строки удручающе часто сопровождается пустой строкой. Мне лично не нравятся фигурные скобки в конце строки, и смешивание их с пустой строкой после фигурной скобки делает бессмысленной нотацию (IMNSHO). Поставьте открытую скобку на следующей строке, и вы получите в основном пустую строку (и, IMNSHO, более читаемый код). Если вы должны использовать скобу K & R в конце строки, не тратьте вертикальное пространство, экономя на посторонних пустых строках.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Напишите то, что наиболее разборчиво и наименее удивительно.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Эта функция не требует 12 строк комментариев к документу.

На самом деле, это не нуждается в комментариях.

Или пустые строки.

Они отвлекли бы от его сути.

Внутри функции? Редко

Если у меня есть четкий другой блок, это рефакторинг для новой функции. Если несколько случаев не стоят этого.

Для меня пустые строки внутри функции - одна из самых неправильных «лучших практик».

Часто

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

Хорошие пробелы

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Плохой пробел

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

против

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

против

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

Я не только использую пробелы, я использую скобки для ясности.

Брекеты, которые я использую, чтобы сказать, что они могут быть функциями.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

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

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

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

...

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

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

Заслуженный профессор дал два великих совета

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

Мои эмпирические правила таковы:

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

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

3. Определение метода: добавить строку

4. Определения модуля / класса: добавить две строки

Мне нравится думать о пробелах так же, как параграф. Вы группируете линии, которые вносят вклад в одну идею.

Если вы начинаете новую идею или новый аспект той же идеи, вы начинаете новый абзац - вот так.

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

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

Пустые строки являются обязательными, на мой взгляд. Я использую их для разделения различных логических блоков кода. Делает код читабельным. Читаемый код - это хороший код;)

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

Конечно, если люди делают это, добавляя несколько пустых строк везде, я нахожу это очень раздражающим :(

Я использую только пробелы внутри функции / метода для разделения объявлений и кода.

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

как правило, в peusdo-коде:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Если я вижу бесполезные пробелы, я обычно съеживаюсь.

Пустое пространство чрезвычайно ценно.

Вот в чем дело ... ботаники, которые пишут сложный код вроде E = MC ² , отлично демонстрируют свои навыки программирования.

Теперь давайте прыгнем вперед на шесть месяцев, и сейчас 2 часа ночи, и система, на которую не смотрели шесть месяцев, сломалась на самой линии E = MC ² . Это почти невозможно отладить ... все волнуются.

Предположим, что код был похож на это ...

See Dick
See Jane
See Dick and Jan

Если это 2:00 утра и код не работает. Быстрый взгляд покажет, что третья строка должна была быть

See Dick and Jane

Проблема решена.

Итог ... используйте пробел.

Как уже говорили многие, пустые строки облегчают чтение кода. Тем не менее, есть некоторые языки, которые применяют этот стандарт. Один из тех, что я могу придумать, но не столько о пустых строках, сколько о правильном отступе) - это Python.

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

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

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

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

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

Пустые строки важны. Однако тратить целую пустую строку на открывающей скобке уменьшает количество кода, который вы можете увидеть на скриншоте. Должно быть:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Не заставляй меня начинать ставить скобку '{' в той же строке, что и 'for' ... это мешугха).

Да. Для удобства чтения. Иногда я даже вставляю пустые строки в код, который не написал. Мне легче понять код, когда они имеют логическую группировку через пустые строки - как вы можете «быстро читать» через него.

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

Например, между функциями или внутри функции, когда мы заканчиваем цикл ...

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

Мы используем пробелы, рекомендованные Microsoft StyleCop. Помимо читабельности и согласованности, я обнаружил, что (вместе с небольшими размерами классов) правильно выстроенный код значительно облегчает управление слияниями, когда разные люди в команде работают над одними и теми же областями.

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

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

 code;
 //
 morecode;

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