perlstyle

СОДЕРЖАНИЕ

• НАЗВАНИЕ
• ОПИСАНИЕ

НАЗВАНИЕ

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

ОПИСАНИЕ

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

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

Краткий способ организовать это — использовать синтаксис use VERSION, запрашивающий версию 5.36 или выше, что включит прагмы strict и warnings (а также несколько других полезных именованных функций).

use v5.36;

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

• Отступ в 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.

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

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

• Используйте 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<>.

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

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