The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

русский перевод perlstyle, стиль написания кода на Perl (perl)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: 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 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). Подумайте, не предложить ли ваш код другим. Подумайте, а не поменять ли вам свои взгляды на мир. Подумайте... а, ну хватит. * Будть последовательны. * Будте элегантны.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, Аноним (1), 08:35, 23/08/2002 [ответить]  
  • +/
    ...Да... Еслибы я ещё понел былобы хорошо
     
  • 2, Caunter (?), 16:11, 25/10/2002 [ответить]  
  • +/
    Siply great, very useful.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2023 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру