Слишком много лишних пробелов? [закрыто]

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

Хотя я вижу две проблемы с этим: 1) Он может увеличить размер файла исходных файлов, даже просто разрыв строки каждые две или три строки могут складываться в длинном файле. Я знаю, что хороший компилятор оптимизирует все пустое пространство (я не уверен, я думаю, LLVM /Clang делает это), но исходный файл по-прежнему большой.

И 2) это может заставить некоторых людей подумать, что я приукрашиваю свой код, чтобы он выглядел длиннее и «больше», чтобы заставить других думать, что я делаю больше работы, чем я на самом деле (рассмотрим 3000 строк против 6000 строк , 3000 - символы новой строки). Который я не делаю этого, кстати. Является ли использование слишком большого количества пробелов с технической точки зрения и /или профессиональной точки зрения?

6 голосов | спросил Milo 26 J000000Saturday14 2014, 05:16:31

11 ответов


20

Есть две причины, по которым вы не должны этого делать:

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

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

ответил Doval 26 J000000Saturday14 2014, 05:40:24
11

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

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

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

Давайте посмотрим на это и получим код. Это от _header_value_parser.py

как написано дополнительные пробелы

Текст не имеет большого значения, но обратите внимание, что это немного меньше на экране. Вы даже не можете получить полный метод на странице. И есть вопросы о том, где расположены некоторые из блоков - глаз не путешествует, что хорошо держит вещи в очереди далеко (это становится более очевидным в full size image - линия 176 выстраивается в линию с объемом 135 или 133?).

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

ответил 26 J000000Saturday14 2014, 05:42:02
10
  

Слишком много лишних пробелов?

Очевидно: Да. Если вы говорите, это слишком много, то это знак, потому что что-то вонючее происходит.

  

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

Ваша проблема не в пробеле, ваша проблема - это clean code или лучше: отсутствие чистого кода.

Один урок чистого кода учит нас: разбивать большие кодовые блоки на более мелкие. Бьюсь об заклад, каждый блок, который вы обертываете в whitespache, является блоком, который можно разбить на маленькие удобные куски.

Попробуйте с паранойей: каждая функция больше 10 строк должна быть разбита на более мелкие куски. И если вы пишете OO: каждый класс длиннее 200 строк слишком большой.

Конечно, 10/200 строк - это произвольное число, но если вы будете следовать этому правилу некоторое время, вы заметите эффекты: а) у вас больше не будет блоков пробелов; b) ваш код становится более компактным, читаемым и лучше понять, и в конце концов: поддерживаемый.

  

Хотя я вижу две проблемы с этим: 1) Он может увеличить размер файла исходных файлов, даже просто разрыв строки каждые две или три строки могут складываться в длинном файле. Я знаю, что хороший компилятор оптимизирует все пустое пространство (я не уверен, я думаю, LLVM /Clang делает это), но исходный файл по-прежнему большой.

Зачем беспокоиться о файлах? Мы не живем в 80-х годах и храним все на пленке. Мы находимся в возрасте Big Data. Это неправильная проблема. И если вы разбиваете свои блоки на читаемые куски, количество файлов и размер увеличится. Но не беспокойтесь.

  

И 2) это может заставить некоторых людей подумать, что я приукрашиваю свой код, чтобы он выглядел длиннее и «больше», чтобы заставить других думать, что я делаю больше работы, чем я на самом деле (рассмотрим 3000 строк против 6000 строк , 3000 - символы новой строки). Который я не делаю этого, кстати. Является ли использование слишком большого количества пробелов с технической точки зрения и /или профессиональной точки зрения?

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

ответил Thomas Junk 26 J000000Saturday14 2014, 18:48:40
6

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

Обновление:

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

Java

Появится одна пустая строка:

  1. Между последовательными членами (или инициализаторами) класса: полями, конструкторами,   методы, вложенные классы, статические инициализаторы, инициализаторы экземпляра.   
    • Исключение: Пустая строка между двумя последовательными     поля (без другого кода между ними) являются необязательными. Такие пустые строки используются по мере необходимости для     создайте логические группировки полей.
  2. Внутри тела методов, по мере необходимости, для создания логических группировок операторов.
  3. Необязательно перед первым членом или после последнего члена класса (ни   поощряется и не поощряется).
  4. В соответствии с требованиями других разделов настоящего документа (например, раздел 3.3,   Операции импорта).

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

Python

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

C ++

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

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

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

Некоторые правила большого пальца, которые помогут вам использовать пустые строки:

  • Пустые строки в начале или конце функции очень редко помогают читать.
  • Пустые строки внутри цепочки блоков if-else могут помочь в удобочитаемости

Objective-C

Пустые строки до и после @interface, @implementation и @end являются необязательными. Если ваш @interface объявляет переменные экземпляра, пустая строка должна появиться после закрытия (}).

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

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

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

ответил Derek Argueta 26 J000000Saturday14 2014, 06:17:13
4

Это зависит от того, что вы подразумеваете под слишком большим количеством пространства. Для меня важно и первостепенно использовать пространство для улучшения читаемости вашего кода. Используйте одну строку, чтобы отделить несколько блоков в функции, свободное пространство между функцией и классом, это хорошо, а символ allign с несколькими языками также может быть прохладным:

sub my_function {
     my $arg = @_;

     my $a       = 42;
     my $b       = 50;
     my $sum     = $a + $b;

     my $map = {
         key         => 'value',
         second => 'second value'
     }

     if ( $sum > $ arg ) {
         return $sum
     }

     return;
}

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

ответил Hobbestigrou 26 J000000Saturday14 2014, 16:09:14
2

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

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

ответил kriss 26 J000000Saturday14 2014, 05:56:03
0

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

if (x)
{
    // do something

    // do more


}

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

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

Итак: быстрый стандарт для вас: 1. Отступ правильно. 2. одиночная пустая строка между блоками, где это необходимо 3. Несколько пустых строк между функциями. 4. нигде else.

Придерживайтесь этого, и у вас будут счастливые коллеги и порядок.

ответил gbjbaanb 26 J000000Saturday14 2014, 17:17:54
0

Это определенно зависит от различных факторов, о которых говорили другие.

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

class Thing

  def method1
    stuff
  end

  def method2
    stuff
  end

end

к

class Thing
  def method1
    stuff
  end
  def method2
    stuff
  end
end

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

Итак, в качестве общего правила для кода, для% от пробельных строк, я бы искал цифру от 10% до 30%. Меньше этого, и у вас есть длинные алгоритмы, более того, и вы можете прокручивать вверх и вниз, теряя контекст и визуализируя группировку «видеть вместе».

Однако, это сказало ...

для некоторых целей, наличие «всего на одном экране» действительно полезно.

Хороший пример, если мой .bashrc-файл, который добрался до 3 или 4 «экранов» и привел к большему:

  • дублирование для тех же настроек
  • конфликтующее использование одинаковых настроек
  • забыть, какие настройки делают

Итак, в этом случае я приложил много усилий, чтобы «сжать» его. В этом случае не просто пробелы, а конструкция if then поместится в 1 строку, например.

test -f ~/.bash_aliases && . $_

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

введите описание изображения здесь>> </p>

<p> Наконец, два вопроса, которые вы упомянули: размер файла и длина заполнения не являются факторами, которые будут знать любые программисты, которых я знаю и уважаю, - помните, что 100 ГБ составляет сто тысяч миллионов байт. Дополнительные линейные пространства просто будут считаться вашим предпочтением для линейного пространства. Если бы код действительно работал, это, как правило, было бы относительно небольшой проблемой, хотя с командой, которая должна быть согласована. </p></body></html>

ответил Michael Durrant 26 J000000Saturday14 2014, 18:22:13
0

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

Это все о читаемости, но читаемость данного образца будет отличаться для разных читателей.

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

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

ответил Zenilogix 26 J000000Saturday14 2014, 22:29:22
0

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

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

Существует несколько аналогичный аргумент в отношении гораздо более распространенной практики чрезмерного использования пространств, возьмите фрагмент кода, например:

while ( x > y || foo != bar || ! ( a in b ) ) {

Используя стиль без пробелов по умолчанию, можно было бы использовать несколько пробелов, чтобы подчеркнуть три отдельные части условия:

while(x>y || foo!=bar || !(a in b)){

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

ответил aaaaaaaaaaaa 30 J000000Wednesday14 2014, 13:46:52
0

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

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

Плюс, как отметил Томас Джанк, более длинные функции будут лучше разделены на более мелкие, более управляемые.

ответил Simon B 30 J000000Wednesday14 2014, 15:45:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132