Подтвердить что ты не робот

Использование вертикальных пробелов

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

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

  • Какие жесткие и мягкие правила вы применяете к вертикальным пробелам?
  • Используются ли какие-либо вертикальные пробелы, которые обычно считаются очень плохими или очень хорошими?
  • Вы нашли код чтения с "правильными" вертикальными пробелами, помогли понять его?
  • Кто-нибудь, кроме типографов и меня заботит?
4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

foo.setBar(1);
foo.setBar2(2);
foo.writeToDatabase();

bar.setBar(1)
bar.setBaz(2);
bar.writeToDatabase();

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

Ответ 3

Если группа операторов логически связана, я даю ей пустую строку до и после. Это разделение помогает, если мне нужно реорганизовать его в функцию позже.

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

Ответ 4

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

В любом месте, где я делаю "что-то", которое принимает несколько строк кода, за которым сразу следует "что-то еще", я либо абстрактно выражусь в отдельные функции, либо размещаю комментарии [*]. Таким образом, строки кода обычно группируются в короткие блоки, за исключением случаев, когда контроль потока делает это (на мой взгляд) самоочевидным.

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

В классах я иногда помещаю пробелы между методами/функциями-членами, а иногда и нет. В С++ я помещаю пробелы перед спецификаторами доступа.

Я помещаю пробелы между классами (иногда не для анонимных внутренних классов в Java) и между функциями вне классов.

Кроме этого, мой код довольно вертикально плотный. Я почти никогда не использую несколько пустых строк, даже при разделении разделов файла заголовка и тому подобного. Я бы предпочел бы blankline-commentline-blankline, а не blankline-blankline, даже если в комментариях будет что-то совершенно банальное, как "вспомогательные функции". Мне не нравятся стили, у которых есть огромные вертикальные пробелы между функциями - если они настолько раздельны, что вы не хотите видеть их одновременно на экране, я бы сказал, либо помещал их в разные файлы, либо заполнял пробел с Doxygen/Javadoc.

[*] В версии я проверяю. Я обычно пишу код более или менее без комментариев, затем компилирую его, запускаю быстрые тесты, комментирую его, запускаю надлежащие тесты и фиксирую их. Это часто меняется немного, а иногда и много. Например, если я кодирую алгоритм, который точно определен заранее, или спецификации, где реализация "очевидна", я могу сначала написать комментарии, а затем код.

Ответ 5

В течение десятилетий было известно, что способность программиста понимать код обычно ограничена тем, насколько он может видеть за один раз. (См., Например, Вайнберг, "Психология компьютерного программирования", "oldie-but-goodie".) В старые времена бумажных списков программисты хватали большие таблицы и распространяли несколько страниц листинга. В настоящее время экранная недвижимость несколько лучше, чем дни 24x80, но я все же склонен минимизировать использование вертикальных пробелов, так как множество пустых строк занимает пространство экрана, которое может показывать мне фактический код.

Ответ 6

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

Более чем одна пустая строка сразу выглядит немного неуместной.

Ответ 7

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