Я основываю большинство на своих сценариях Perl на следующем шаблоне/скелете:
#!/usr/bin/perl -w
use strict;
use utf8;
$| = 1;
binmode(STDOUT, ":utf8");
# my code goes here.
Достигнутые этим шаблоном вещи:
-w)use strict)use utf8 + binmode(STDOUT, ":utf8"))$| = 1)Мой вопрос:
Как мой шаблон может быть улучшен, чтобы лучше отражать передовые методы Perl?
Замените -w на use warnings. Это позволяет вам отключать предупреждения лексически, если вам нужно. См. perllexwarn.
Прагма use utf8 предназначена для вашего исходного кода в UTF-8. Если это так, здорово. Если нет... Я не рекомендую добавлять вещи, которые вы фактически не используете. Аналогичным образом, не устанавливайте STDOUT в UTF-8, если вы его не производят.
Отключение буферизации приведет к снижению производительности. Не делайте этого, если вам не нужно, а затем ограничьте область действия блоком, где это необходимо.
Мне нравится включать инструкцию для явного указания минимальной версии Perl, необходимой для запуска script. Это делает сообщения об ошибках более значимыми, если они не компилируются из-за того, что кто-то использует более старую версию Perl. например.
BEGIN { require 5.00801 }
Я использую это особое заклинание вместо чего-то вроде use v5.8.1, потому что он обратно совместим с версиями Perl. Я пытаюсь "поддерживать" значимое сообщение об ошибке.
Здесь мой, хотя я должен признать, что иногда я просто начинаю печатать без использования шаблона. Я установил его как modulino, поэтому легко добавить к нему тестирование позже:
#!perl
package App::XXX;
use utf8;
use 5.010;
use strict;
use warnings;
use vars qw($VERSION);
$VERSION = '0.01_01';
__PACKAGE__->run( @ARGV ) unless caller;
sub run
{
my( $class, @args ) = @_;
}
1;
Если вы хотите автоматически установить все ваши дескрипторы файлов на некоторую кодировку, вы можете добавить open прагма:
use open IO => ':utf8';
У меня есть другой шаблон для документации, который я добавляю позже.
Кроме того, некоторые люди имеют последовательности редакторов, которые они добавляют в качестве комментариев в верхней или нижней части script. Возможно:
# -*- Mode: cperl; coding: utf-8; cperl-indent-level: 4 -*-
# vim: ts=4 sts=4 sw=4:
Поскольку я помещаю свои скрипты в дистрибутивы, процесс установки автоматически фиксирует строку shebang, поэтому не имеет значения, что я там помещаю.
Как насчет того, чтобы загрузить некоторую документацию?
=head1 NAME
name here
=head2 SYNOPSIS
short synopsis here
Не то, что это может быть достигнуто в шаблоне как таковом, но вы можете применять лучшие практики perl, заставляя разработчиков запускать perltidy и perlcritic во всем исходном коде. Более того, Perl Best Practices - это обязательно прочитайте, если вы спросите меня.
Что касается вашего шаблона, единственное, что вы должны рассмотреть, это скобки после встроенной функции binmode, поскольку они не требуются (это одна из многих рекомендаций в книге).
Измените строку интерпретатора на
#!/usr/bin/env perl
Это предотвратит использование -w, поэтому вам также придется
use warnings;
Еще одна вещь, которую вы можете посмотреть, - это модуль Toolkit на CPAN. Созданный Damian Conway, он позволяет собирать набор часто используемых модулей, а затем использовать одну строку "use" вместо нескольких. Поэтому вместо
use strict;
use warnings;
use foo;
use bar;
У вас будет:
use Toolkit;
и все модули, которые вы разместили в своем наборе инструментов, будут доступны.
Я бы сказал, что вы хотите включить стандартный набор документации POD в свой шаблон, с нормальным набором заголовков, который вы видите в большинстве модулей на CPAN. Мне нравится включать это в конце, но вам может понравиться это в верхней части или даже вкрапленное через код. например в конце:
1;
__END__
=head1 NAME
My::Foo - The great new My::Foo!
=head1 VERSION
Version 0.01
=head1 SYNOPSIS
=head1 DESCRIPTION
=head1 METHODS
=head2 new
=head1 AUTHOR
=head1 BUGS
=head1 ACKNOWLEDGEMENTS
=head1 COPYRIGHT & LICENSE
This program is free software; you can redistribute it and/or modify it
under the terms of either: the GNU General Public License as published
by the Free Software Foundation; or the Artistic License.
See http://dev.perl.org/licenses/ for more information.
=cut
Я нахожу запись своего модуля, как будто я собираюсь выпустить его в CPAN, даже если я никогда не буду хорошей идеей. Для получения более мудрости и лучшей практики ознакомьтесь с module-starter. sudo cpan Module::Starter. Этот удобный инструмент поможет вам создать полный скелет модуля, который наиболее поучителен для просмотра. например.
$ module-starter --module=My::Foo --author=markp [email protected] --mb
$ tree My-Foo
Я никогда не использую строку shebang в моих сценариях .pl, и я не использую use lib /path/to/special/lib, чтобы позволить им настраиваться для каждого вызова:
perl -I/path/to/special/lib myscript.pl
/usr/local/perl5.10 -I/different/path/to/lib myscript.pl
И, конечно, каждый файл начинается с:
use strict;
use warnings;
Изменить. Я подумал о нескольких вещах, которые я начал использовать совсем недавно:
# at least while the project is in initial development, so as to
# expose more places where the module might die; maybe turn off
# in production, depending on what other error handling is in place
use autodie;
# ...after all other 'use' lines at the top of a module: remove all
# unwanted imports cluttering up our namespace
use namespace::autoclean;
Хотя не все, что я делаю Perl для Интернета, это происходит достаточно часто, поэтому я вынужден добавить:
use CGI::Carp qw(fatalsToBrowser);
к моему шаблону разработки, который я комментирую, когда он попадает в производство.
Мне не кажется нужным, чтобы по умолчанию отключить буферизацию.