Почему плохо помещать пробел перед точкой с запятой?

Ответ 1

В первом абзаце раздела "Описание":

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

И из третьего абзаца раздела "Описание":

Что касается эстетики кода, то единственное, о чем сильно беспокоит Ларри, это то, что закрывающая фигурная скобка многострочного BLOCK должна совпадать с ключевым словом, которое запустило конструкцию. Кроме того, у него есть другие предпочтения, которые не так сильны:

Это просто соглашение между программистами Perl для стиля. Если вам это не нравится, вы можете игнорировать его. Я бы сравнил его с Руководством по Java Java Style или предложения для отступов в книге K & RC.. В некоторых средах есть свои собственные рекомендации. Это просто предложения для Perl.

Как Джон Скит сказал в удаленном ответе на этот вопрос:

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

Ответ 2

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

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

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

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

my $foo = $boolean ?
            $some_long_value
                  :
            $some_other_value
                  ;

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

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

Ответ 3

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

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

Но.

Ответ 4

Как и другие, это вопрос стиля, а не жесткое правило. Например, мне не нравится четыре пробела для отступов. Я являюсь реальной вкладкой для отступов в блочном уровне/пробелов, которые выставляют вещи вроде программиста, поэтому я игнорирую этот раздел perlstyle.

Мне также нужна причина для стиля. Если вы не можете четко указать, почему вы предпочитаете данный стиль, тогда правило бессмысленно. В этом случае причина довольно легко увидеть. Пробелы, которые не требуются, используются, чтобы привлечь внимание к чему-либо или сделать что-то более легкое для чтения. Значит, точка с запятой заслуживает дополнительного внимания? Каждое выражение (запрещающее структуры управления) заканчивается точкой с запятой, и большинство выражений соответствуют одной строке. Поэтому привлечение внимания к ожидаемому случаю кажется пустой тратой времени и внимания программистов. Вот почему большинство программистов выделяют строку, которая является продолжением выражения, чтобы обратить внимание на то, что он не заканчивался на одной строке:

open my $fh, "<", $file
    or die "could not open '$file': $!";

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

foo("bar") ;

легче читать, чем

foo("bar");

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

Ответ 5

Не стесняйтесь помещать пробел. Важно то, что вы последовательны; согласованность позволяет более легко выявлять ошибки.

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

Обновление: пример этого стиля кодирования (который я не сторонник):

; sub capture (&;*)
   { my $code = shift
   ; my $fh   = shift || select
   ; local $output     
   ; no strict 'refs'
   ; if ( my $to = tied *$fh )
      { my $tc = ref $to
      ; bless $to, __PACKAGE__
      ; &{$code}()
      ; bless $to, $tc
      }
      else
      { tie *$fh , __PACKAGE__
      ; &{$code}()
      ; untie *$fh
      }
   ; \$output
   }

Защиту можно найти здесь: http://perl.4pro.net/pcs.html.

(Обновление 2011 года: эта страница, похоже, прошла AWOL, здесь можно найти спасенную копию: http://ysth.info/pcs.html)

Ответ 6

Ну, это style, а не правило. Правила стиля по определению довольно произвольны. Что касается того, почему вы не должны помещать пробелы перед точкой с запятой, это просто потому, что это "Путь к нему". Не только с Perl, но и с C и всеми другими языками curlies-and-semicolons, возвращающимися на C и более новыми C-влиятельными, такими как С++, С#, Objective C, Javascript, Java, PHP и т.д.

Ответ 7

Потому что люди этого не ожидают. Странно, когда вы это делаете.

Ответ 8

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

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

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

Ответ 9

Мне это действительно не нравится. Но это 100% личное решение и групповое соглашение, которое вы должны сделать.

Ответ 10

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

Чтобы сделать сравнение реальной жизни, у нас есть трафик с красным, желтым/оранжевым и зеленым. Несмотря на психологический эффект от цветов, не стоит использовать Purple, Brown и Pink, но только потому, что мы все привыкли к цветам, есть меньше трафических аварий.