русский перевод perlstyle, стиль написания кода на Perl (perl)
Ключевые слова: perl, (найти похожие документы)
Date: Fri, 1 Mar 2002 13:51:36 +0000 (UTC)
From: Andrey Sapozhnikov <sapa@icb.chel.su>
Newsgroups: fido7.ru.perl
Subject: русский перевод perlstyle, стиль написания кода на Perl
> Кто-нибудь видел в Inete русский перевод perlstyle? Буду признателен за
> ссылку.
Под впечатлением того, что кто-то заинтересовался этим основополагающим
документом вместо задавания дурацких вопросов, рискну взять, да перевести
прямо сюда. Благо текст короткий, а времени свободного есть немного :)
Вычитки, корректуры и худ. обработки не делал. Постарался перевести на
"великий и могучий" максимум, может даже больше чем следовало :(
Надеюсь, после корректуры, никто не станет больше задавать вопросы
не повесив предварительно этот текст у себя над рабочим столом и не
задавшись выучить его наизусть до того, как приставать со своими скриптами
к другим. Надеюсь, что мир измениться к лучшему :)
Андрей
НАЗВАНИЕ
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 analysisn" if $verbose;
лучше чем
$verbose && print "Starting analysisn";
поскольку ключевым является не то, напечатал ли пользователь -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). Подумайте, не предложить
ли ваш код другим. Подумайте, а не поменять ли вам свои взгляды на мир.
Подумайте... а, ну хватит.
* Будть последовательны.
* Будте элегантны.
644 Прочтений • [русский перевод perlstyle, стиль написания кода на Perl (perl)] [08.05.2012] [Комментариев: 0]
Vova
