НАЗВАНИЕ
     perlstyle - Руководство по стилю Perl

ОПИСАНИЕ
     Конечно, у каждого программиста будут собственные предпочтения в
     плане форматирования, но есть несколько основовных правил, выполнение
     которых обеспечит вашему коду лучшую читаемость, понимаемость и
     легкость в сопровождении.

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

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

         Продолжая сказанное, только то, что вы *MOЖЕТЕ* опустить скобки
         во многих местах, не означает того, что вам следует делать так:

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

         Когда сомневаетесь, ставьте скобки. В крайнем случае, пусть какой-
         нибудь бедный schmuck потопчет клавишу % в vi.

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

     *   Не идите на поводу глупостей, заканчивая цикл обязательно в начале
         или в конце, когда Perl предоставляет вам оператор "last" и вы можете
         выйти в середине. Просто "втяните" его чуть-чуть, чтоб сделать более
         видимым:

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

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

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

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

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

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

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

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

             $ALL_CAPS_HERE только константы (остерегайтесь пересечения с
                             "системными" переменными Perl!)
             $Some_Caps_Here  глобальная/статическая уровня пакета
             $no_caps_here    локальная переменная или переменная с локальной
                              вилимостью (my) уровня функции

         Имена функций и методов, лучше выглядят строчными буквами. Т.е.
         $obj->as_string().

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

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

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

     *   Используйте описания документов с помощью конструкций типа "<<END"
         вместо повторяющихся 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). Подумайте, не предложить
         ли ваш код другим. Подумайте, а не поменять ли вам свои взгляды на мир.
         Подумайте... а, ну хватит.

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

     *   Будте элегантны.