Каков правильный способ форматирования кода?

Ответ 1

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

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

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

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

РЕАЛЬНЫЕ ПРОГРАММЫ

Ответ 2

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

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

Ответ 3

Похоже на то, что у меня есть похожие строки.

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

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

ИЗМЕНИТЬ:... не более высокие устремления, чем "реальный мир", но выше, чем посредственное дерьмо, распространенное в "реальном мире".... если у вас действительно есть более высокие устремления, чем "реальный мир", вы можете увидеть профессионала.; -)

Ответ 4

Мое правило:

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

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

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

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

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

Ответ 16

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

2) В моем офисе много недостатка межстрочного интервала, потому что "вы можете увидеть больше кода на одной странице таким образом". Они также помещают несколько операторов в одну строку, и более (IMHO) используют?:... Я ненавижу это.

3) Я не согласен с фразой "Вот почему он учитель". как (бывший) учитель, я должен сказать, что я бы понизил людей, чтобы не помещать пространство между разделами, прежде чем я снял очки за помещение. Не думаю, что и я. Я хочу сказать, что он, будучи задницей, ортогонален тому, что он учитель. (EDIT: этот раздел отредактирован из оригинала, но я оставляю его здесь, чтобы сохранить правило 3...)

Не злоупотребляйте учителями!

Ответ 17

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

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

Ответ 18

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

Ответ 19

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

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

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

Ответ 20

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

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

Ответ 21

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

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

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

Ответ 22

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

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

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);
    }
}

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

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

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