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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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