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

Question

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

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

• Какие жесткие и мягкие правила вы применяете к вертикальным пробелам?
• Существуют ли какие-либо виды использования вертикальных пробелов, которые обычно считаются очень плохой или очень хорошей практикой?
• Помогло ли вам чтение кода с «правильными» вертикальными пробелами в его понимании?
• Кто-нибудь, кроме типографы и меня это волнует?

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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