perlstyle

СОДЕРЖАНИЕ

• ИМЯ
• ОПИСАНИЕ

ИМЯ

perlstyle - Руководство по стилю Perl

ОПИСАНИЕ

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

Самое важное — использовать strict и warnings во всем вашем коде или знать причину, почему не стоит этого делать. Вы можете отключить их явно для отдельных частей кода с помощью no warnings или no strict, и это может быть ограничено конкретными предупреждениями или функциями strict, которые вы хотите отключить. Флаг -w и $^W переменную не следует использовать для этой цели, так как они могут повлиять на код, который вы используете, но не написали, такой как модули из ядра или CPAN.

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

• Отступы в 4 столбца.

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

• Пробел перед открывающей фигурной скобкой многострочного блока.

• Один блок может быть помещен на одну строку, включая фигурные скобки.

• Пробел перед точкой с запятой отсутствует.

• Точка с запятой опущена в «коротком» одномерном блоке.

• Пробел вокруг большинства операторов.

• Пробел вокруг «сложного» индекса (внутри скобок).

• Пустые строки между фрагментами, которые выполняют разные действия.

• else без вложенности.

• Пробел отсутствует между именем функции и ее открывающей скобкой.

• Пробел после каждой запятой.

• Длинные строки разделяются после оператора (за исключением and и or).

• Пробел после последней скобки, соответствующей текущей строке.

• Выравнивание соответствующих элементов вертикально.

• Опускание избыточных знаков препинания, пока это не повлияет на ясность.

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

Вот некоторые другие более существенные вопросы стиля, о которых следует подумать:

• Просто потому, что вы МОЖЕТЕ сделать что-то определённым способом, не означает, что вы ДОЛЖНЫ это делать. Perl разработан, чтобы дать вам несколько способов сделать что-либо, поэтому подумайте о выборе наиболее удобочитаемого. Например

  open(my $fh, '<', $foo) || die "Can't open $foo: $!";

  лучше, чем

  die "Can't open $foo: $!" unless open(my $fh, '<', $foo);

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

  print "Starting analysis\n" if $verbose;

  лучше, чем

  $verbose && print "Starting analysis\n";

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

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

  В том же духе, просто потому, что вы МОЖЕТЕ опустить скобки во многих местах, не означает, что вы должны это делать:

  return print reverse sort num values %array;
  return print(reverse(sort num (values(%array))));

  В случае сомнений, используйте скобки. По крайней мере, это позволит кому-то нажать на клавишу % в vi.

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

• Не делайте бессмысленных действий, чтобы выйти из цикла в верхней или нижней части, когда Perl предоставляет оператор last, чтобы вы могли выйти из середины. Просто «сместите» его немного, чтобы сделать его более заметным:

  LINE:
      for (;;) {
          statements;
        last LINE if $foo;
          next LINE if /^#/;
          statements;
      }

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

• Избегайте использования grep() (или map()) или `backticks` в пустом контексте, то есть когда вы просто выбрасываете их возвращаемые значения. У этих функций есть возвращаемые значения, поэтому используйте их. В противном случае используйте цикл foreach() или функцию system() вместо них.

• Для переносимости, при использовании функций, которые могут не быть реализованы на каждой машине, проверьте конструкцию в eval, чтобы увидеть, произойдет ли ошибка. Если вы знаете, какая версия или патч уровень данной функции был реализован, вы можете проверить $] ($PERL_VERSION в English), чтобы увидеть, будет ли она там. Модуль Config также позволит вам просмотреть значения, определенные программой Configure при установке Perl.

• Выбирайте мнемонические идентификаторы. Если вы не можете вспомнить, что означает мнемоника, у вас проблемы.

• Хотя короткие идентификаторы, такие как $gotit , вероятно, в порядке, используйте подчеркивания для разделения слов в более длинных идентификаторах. Обычно легче читать $var_names_like_this , чем $VarNamesLikeThis, особенно для носителей языка, не являющегося английским. Это также простое правило, которое работает последовательно с VAR_NAMES_LIKE_THIS.

  Имена пакетов иногда являются исключением из этого правила. Perl неформально резервирует имена модулей в нижнем регистре для модулей «pragma», таких как integer и strict . Другие модули должны начинаться с заглавной буквы и использовать смешанный регистр, но, вероятно, без подчеркиваний из-за ограничений в представлениях имён модулей файловыми системами как файлов, которые должны уместиться в нескольких разряженных байтах.

• Вам может быть полезно использовать регистр букв для указания области или характера переменной. Например:

  $ALL_CAPS_HERE   constants only (beware clashes with perl vars!)
  $Some_Caps_Here  package-wide global/static
  $no_caps_here    function scope my() or local() variables

  Имена функций и методов, похоже, лучше всего работают в нижнем регистре. Например, $obj->as_string().

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

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

• Используйте новые операторы and и or , чтобы избежать необходимости ставить скобки в операторах списка так много, и чтобы уменьшить частоту операторов пунктуации, таких как && и || . Вызывайте ваши подпрограммы как если бы они были функциями или операторами списка, чтобы избежать чрезмерного использования амперсандов и скобок.

• Используйте here документы вместо повторяющихся print() инструкций.

• Выравнивайте соответствующие вещи вертикально, особенно если они слишком длинные, чтобы поместиться на одной строке.

  $IDX = $ST_MTIME;
  $IDX = $ST_ATIME       if $opt_u;
  $IDX = $ST_CTIME       if $opt_c;
  $IDX = $ST_SIZE        if $opt_s;
  
  mkdir $tmpdir, 0700 or die "can't mkdir $tmpdir: $!";
  chdir($tmpdir)      or die "can't chdir $tmpdir: $!";
  mkdir 'tmp',   0777 or die "can't mkdir $tmpdir/tmp: $!";

• Всегда проверяйте коды возврата системных вызовов. Хорошие сообщения об ошибках должны направляться в STDERR, включать, какая программа вызвала проблему, какие системные вызовы и аргументы потерпели неудачу, и (ЧРЕЗВЫЧАЙНО ВАЖНО) должны содержать стандартное системное сообщение об ошибке о том, что пошло не так. Вот простой, но достаточный пример:

  opendir(my $dh, $dir)        or die "can't opendir $dir: $!";

• Выравнивайте транслитерации, когда это имеет смысл:

  tr [abc]
     [xyz];

• Подумайте о возможности повторного использования. Зачем тратить умственные усилия на одноразовое использование, когда вы, возможно, захотите сделать что-то подобное снова? Подумайте о генерализации своего кода. Подумайте о написании модуля или класса объектов. Подумайте о том, чтобы ваш код работал без ошибок с use strict и use warnings. Подумайте о том, чтобы отдать свой код. Подумайте о том, чтобы изменить все свои взгляды на мир. Подумайте... ладно, не надо.

• Постарайтесь задокументировать свой код и использовать форматирование Pod последовательно. Вот общепринятые соглашения:

  • Используйте C<> для имён функций, переменных и модулей (и в более общем смысле для всего, что можно считать частью кода, таких как дескрипторы файлов или определённые значения). Обратите внимание, что имена функций считаются более читаемыми со скобками после их имени, то есть function().

  • Используйте B<> для имён команд, таких как cat или grep.

  • Используйте F<> или C<> для имён файлов. F<> должен быть единственным кодом Pod для имён файлов, но поскольку большинство форматировщиков Pod отображают его курсивом, пути Unix и Windows с их косыми и обратными косыми чертами могут быть менее читаемыми, и лучше отображены с помощью C<>.

• Будьте последовательны.

• Будьте вежливы.