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

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

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

  • какие жесткие и мягкие правила вы применяете к вертикальным пробелам?
  • существуют ли вертикальные пробелы, которые обычно считаются очень плохими или очень хорошей практикой?
  • вы нашли, что чтение кода с "правильными" вертикальными пробелами помогло в его понимании?
  • кто-нибудь кроме Печатники а мне не все равно?
11
language-agnostic literate-programming whitespace

7 ответов

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

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

17

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

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

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

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

6

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

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

6

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

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

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

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

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

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

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

3

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

2

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

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

1

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

1