Как правильно форматировать код?

Я следую рекомендациям Microsoft для C #.

Изменить: стандарт для C # - Дон не бороться с IDE. Если вы нажмете CTRL K+D, IDE автоматически вставит пустые строки между разделами кода.

Чтобы понять это, если вы посмотрите пример кода C # на MSDN или в любом другом месте, обычно между каждой логически размещенной группой есть пустая строка. Таким образом, будет пустая строка после всех ваших переменных-членов, пустая строка после каждого метода и т. Д.

В ответ на комментарии, выражающие шок и ужас по поводу того, что я использую IDE для программирования на C #:

НАСТОЯЩИЕ ПРОГРАММАТОРЫ

Я думаю, что делаю что-то подобное, но жестких правил нет. Мне нравится, когда код размещается в «абзацах» сгруппированной / связанной логики.

Код без лишних пробелов читать ужасно.

Похоже, я разделяю строчки кода, похожего на вас.

Но это неуместное личное предпочтение, и у каждого будет свой «правильный способ» сделать это. ИМХО, самое главное - это адаптировать стиль среды, в которую вы входите.

Кроме того, вы найдете такой код в «реальном мире» ... но похоже, что у вас более высокие устремления. ;-)

РЕДАКТИРОВАТЬ: ... не более высокие устремления, чем «реальный мир», но более высокие, чем посредственное дерьмо, обычное в «реальном мире». ... однако, если у вас есть более высокие стремления, чем в «реальном мире», вы можете обратиться к профессионалу. ;-)

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

Поместите одну пустую строку между блоками кода, которые можно описать одним комментарием.

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

Поскольку у нас нет примера вашего личного представления о «логическом» межстрочном интервале, мы не можем точно сказать, заслуживали ли вы понижения рейтинга.

Я стараюсь группировать похожие утверждения или шаги в последовательности вместе перед интервалом (например, объявления переменных, циклы и т. Д.)

В основном то же самое, что говорят все. В COBOL были очень разные правила относительно того, что такое предложение и абзац. Думаю, в глубине души я следую за ними. Если у вас большой оператор IF, вы не ставите точку до самого конца гнезда. Точно так же я помещаю пустую строку после моего последнего} // end if

И да, я помещаю // end if, // end for, // end method stuff туда. Некоторым из более вокальных людей, которых я знаю, это не нравится, но мне это нравится. Они говорят, что вы не должны делать свои if-выражения огромными и что вы, вероятно, неправильно кодируете, если вам НУЖНЫ элементы // end if, а мне НЕ НУЖНО это, но я считаю, что это облегчает чтение. Называйте меня старомодным, ОКР, как угодно.

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

Похоже, ваш учитель в основном придурок. Как говорится, «те, кто может, делайте; те, кто не может, на StackOverflow учат». ;)

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

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

Ваш учитель, вероятно, был наполовину прав в том, что в реальном мире у вас не будет межстрочного интервала. Конечно, в кодовых базах Big Ball of Mud, с которыми я сталкивался, вам повезло, если у вас есть пробел, не говоря уже о комментариях к объяснению.

Помимо того, что 73-летний программист, который написал большую часть этого Big Ball of Mud, все еще работает там, и его объяснение состоит в том, что двоичные файлы должны быть как можно меньше, я не стал проверять, соответствуют ли компиляторы от 20 до 30 лет назад были настолько неэффективными, что не могли удалить пробелы, но я несколько скептически отношусь к этому.

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

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

Я считаю код статьей. Вы когда-нибудь пытались прочитать 2 страницы статьи, в которой нет абзаца или межстрочного интервала?

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

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

Если вы не разделяете блоки 5 или 10 строками пробелов (что сведет кого-нибудь с ума), ваш инструктор - просто задница.

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

Хотя мы должны стремиться не писать методы длиной в 200 строк, все наши короткие методы по-прежнему часто содержат более одного элемента потока управления, и мы должны понимать, что вертикальные пробелы так же важны, как и горизонтальные пробелы для удобочитаемости. Вы можете удовлетворить принципу «единый метод, единственная цель», даже если вы поместите пустую строку между циклом for и оператором if в одном и том же методе.

[Edit to add] И еще несколько комментариев:

1) Очень самонадеянно, что несколько человек в этом потоке предполагают, что OP пишет 200-строчные методы или что существует необходимая корреляция между добавлением пустых строк и написанием неаккуратных методов.

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

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

Я только что работал над кодом, идущим в противоположном направлении; каждый оператор отделяется от следующего пустой строкой. Авторам также понравилось использовать четыре строки комментария с выравниванием по правому краю в столбце 60 вместо однострочного комментария с отступом на уровне кода. Его трудно читать, и его утомительно исправлять. Еще одна особенность кода (код C), разрыв из предыдущего случая «прикрепляется» к регистру следующего, но после регистра есть пустая строка, отделяющая его от кода. Крик!

Пустые строки вокруг блоков кода - это хорошо. Не иметь слишком большого количества блоков кода в одной функции - это хорошо. Пустые строки вокруг каждой строчки кода неприятны. Слишком много или слишком мало хорошего - это плохо.

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

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

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

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

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

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

/* This section preps the widgets for display */
block 
of some 
code

/* This section passes the widgets to the display handler */
and 
so 
on

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

1) Я согласен с вами насчет межстрочного интервала

2) В моем офисе очень часто не хватает межстрочного интервала, потому что «таким образом вы можете увидеть больше кода на одной странице». Еще они помещают несколько операторов в одну строку, а более (ИМХО) используют?: ... Ненавижу.

3) Я не согласен с фразой «Вот почему он учитель». как (бывший) учитель, я должен сказать, что я бы снизил оценку людей за то, что они НЕ помещали пробелы между разделами, прежде чем я сниму баллы за размещение пробелов. Я тоже не думаю. Я хочу сказать, что то, что он осел, ортогонален тому, что он учитель. (РЕДАКТИРОВАТЬ: этот раздел был отредактирован из оригинала, но я оставляю его здесь, чтобы сохранить правило 3 ...)

Не злословите учителей!

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

Вот что такое абзацы. Как и в письменной форме, линии - это быстрый и наглядный способ разделения понятий. Это не означает, что каждый абзац выше должен быть разбит на отдельный ответ; это не значит, что каждый «параграф» кода должен быть разбит на отдельный метод.

Это глупая жалоба. Если бы еще можно было поговорить с этим профессором, я бы объяснил, что означает «стена текста».

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

Я не собираюсь предлагать какие-либо подробности. Здесь и в других местах в сети есть много хороших предложений.

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

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

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

Вот метод, который я только что скопировал и вставил из проекта:

public static void Startup(bool startupUser)
{
    URI = "";
    AutoComplete = new AutoCompleteWrapper();
    SessionToken = Guid.Empty;
    ExternalDataSetLock = new object();

    ConfigDS.Init();
    CalendarDS.Init();
    CalendarDSBuilder.Init();

    if (startupUser && UserName != null)
    {
        string autoCompleteFilename = Path.Combine(UserFolder, "autocomplete.xml");
        AutoComplete.Load(autoCompleteFilename);
    }
}

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

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

Но милосердие, это еще не причина, чтобы их не использовать.

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

Руководство по дизайну для Разработчики библиотеки классов