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()) или обратных кавычек в контексте "ничего", то есть когда вы просто выбрасываете их возвращаемые значения. У всех этих функций есть возвращаемые значения, поэтому используйте их. В противном случае используйте цикл 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 , чтобы избежать необходимости ставить скобки вокруг операторов списков так часто и уменьшить частоту использования операторов пунктуации, таких как && и ||. Вызывайте ваши подпрограммы так, как будто они были функциями или операторами списков, чтобы избежать чрезмерного использования амперсандов и скобок.

• Используйте здесь документы вместо повторяющихся 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<>.

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

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