perlstyle - Интернет в облаке

ПРОГРАММА:

ИМЯ

perlstyle - руководство по стилям Perl

ОПИСАНИЕ

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

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

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

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

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

· Пробел перед открывающим фигурным элементом многострочного БЛОКА.

· Однострочный БЛОК может быть размещен на одной строчке, включая фигурные.

· Перед точкой с запятой не должно быть пробелов.

· Точка с запятой опущена в «коротком» однострочном БЛОКЕ.

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

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

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

· Необнимаемые elses.

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

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

· Длинные строки, прерванные после оператора (кроме «и» и «или»).

· Пробел после последнего совпадения скобок в текущей строке.

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

· Избегайте лишних знаков препинания, пока не пострадает ясность.

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

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

· Просто потому, что ты CAN делать что-то определенным образом не означает, что вы ДОЛЖЕН сделать это
сюда. Perl разработан, чтобы дать вам несколько способов делать что угодно, поэтому рассмотрите
выбирая наиболее читаемый. Например

open (FOO, $ foo) || die "Не могу открыть $ foo: $!";

лучше, чем

die "Не могу открыть $ foo: $!" если не открыто (FOO, $ foo);

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

выведите "Запуск анализа \ n", если $ verbose;

лучше, чем

$ verbose && print "Запуск анализа \ n";

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

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

В том же духе, только потому, что вы CAN опускать круглые скобки во многих местах не
означают, что вам следует:

вернуть печать обратная сортировка num values% array;
return print (reverse (sort num (values ​​(% array))));

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

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

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

ЛИНИЯ:
для (;;) {
заявления;
последняя СТРОКА, если $ foo;
следующая СТРОКА if / ^ # /;
заявления;
}

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

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

· Для переносимости при использовании функций, которые могут быть реализованы не на каждой машине,
протестируйте конструкцию в eval, чтобы убедиться, что она терпит неудачу. Если вы знаете, какая версия или
на уровне исправлений была реализована конкретная функция, вы можете протестировать $] ($ PERL_VERSION в
"Английский"), чтобы узнать, будет ли он там. Модуль «Конфигурация» также позволит вам
опросить значения, определенные Настроить программа при установке 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 () или local () переменные

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

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

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

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

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

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

$ IDX = $ ST_MTIME;
$ IDX = $ ST_ATIME, если $ opt_u;
$ IDX = $ ST_CTIME, если $ opt_c;
$ IDX = $ ST_SIZE, если $ opt_s;

mkdir $ tmpdir, 0700 or die "не могу mkdir $ tmpdir: $!";
chdir ($ tmpdir) или die "не могу chdir $ tmpdir: $!";
mkdir 'tmp', 0777 or die "не могу mkdir $ tmpdir / tmp: $!";

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

opendir (D, $ dir) или die "не могу opendir $ dir: $!";

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

тр [абв]
[xyz];

· Подумайте о возможности повторного использования. Зачем тратить мозги на одноразовое задание, если вы, возможно, захотите это сделать
что-то вроде того снова? Рассмотрите возможность обобщения вашего кода. Подумайте о написании модуля
или класс объекта. Подумайте о том, чтобы ваш код работал чисто с использованием "строгого использования" и "использования".
предупреждения »(или -w) в результате. Подумайте о том, чтобы раздать свой код. Рассмотрите возможность изменения вашего
мировоззрение. Подумайте ... о, неважно.

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

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

· Используйте "B <>" для имен команд, например кошка or GREP.

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

· Быть последовательным.

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

Используйте perlstyle онлайн с помощью сервисов onworks.net