perlstyle

СОДЕРЖАНИЕ

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

ИМЯ

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

ОПИСАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

• Непривязанные else.

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

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

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

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

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

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

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

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

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

  open(FOO,$foo) || die "Can't open $foo: $!";

  лучше, чем

  die "Can't open $foo: $!" unless open(FOO,$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 неофициально зарезервировал имена модулей с маленькими буквами для модулей «псевдонима», таких как 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(D, $dir)     or die "can't opendir $dir: $!";

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

  tr [abc]
     [xyz];

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

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

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

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

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

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

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