Jakiej sieci bezpieczeństwa używasz w Perlu?

Question

Którego safety net używasz?

używać ostrzeżeń;

lub

zastosowanie surowe;

wiem, że

Potencjalnym problemem złapany przez użycie surowe; spowoduje, że twój kod zatrzyma się natychmiast po jego napotkaniu, podczas korzystania z ostrzeżeń; będzie jedynie dawać ostrzeżenie (jak przełącznik linii poleceń -w) i pozwolić na uruchomienie twojego kodu.

Nadal chcę wiedzieć, który z nich jest najczęściej używany przez programistów Perl. Który z nich widział najbardziej używany?

Answer 1

generuje błąd, jeśli używasz symbolicznych odniesień (np. Ciągi znaków do reprezentowania nazw symboli). Generuje błąd, jeśli używasz zmiennej bez deklarowania jej (zachęca to do użycia zmiennych "zmiennych" o nazwie "my", ale jest również spełniona, jeśli prawidłowo zadeklarujesz globale pakietów). Generuje również błąd, jeśli pozostawisz w skrypcie bezmyślne słowa (nie cytowane ciągi, w zasadzie według definicji cytatów Perla). W przypadku "strict" można włączać i wyłączać dowolną z trzech kategorii zwężeń, a moja robię to w ramach bloków o ograniczonym zasięgu. Najlepszą praktyką jest włączanie ograniczeń, ale czasami uzasadniony kod wymaga, aby niektóre z jego funkcji były wyłączone lokalnie. Trzeba jednak długo i mocno zastanawiać się, czy jest to naprawdę konieczne i czy ich rozwiązanie jest idealne. O ograniczeniach można przeczytać w POD, zatytułowanym "strict".

use warnings generuje komunikat ostrzegawczy na podstawie wielu kryteriów, które opisano w POD "perllexwarn". Te ostrzeżenia nie mają nic wspólnego ze zwężeniami, ale raczej należy zwrócić uwagę na najczęstsze "błędy", które można napotkać w ich programowaniu. Najlepiej stosować ostrzeżenia podczas pisania skryptów. W niektórych przypadkach, gdy wiadomość może być niepożądana, pewna kategoria ostrzeżenia może być wyłączona lokalnie w zasięgu. Dodatkowe informacje opisano w "ostrzeżeniach".

use diagnostics czyni ostrzeżenia bardziej gadatliwymi, aw środowisku rozwojowym lub naukowym, szczególnie wśród przybyszów, jest to wysoce pożądane. Diagnostyka prawdopodobnie zostanie pominięta w "produkcie końcowym", ale w fazie rozwoju mogą być naprawdę miłym dodatkiem do generowanych normalnie wiadomości. O diagnostyce można przeczytać w "Diagnostyce Perla POD".

Nie ma powodu, aby zmuszać się do korzystania tylko z jednej z powyższych opcji. W szczególności należy stosować ostrzeżenia i używać stricte, które powinny być używane zarówno w nowoczesnych programach Perla.

We wszystkich przypadkach (z wyjątkiem diagnostyki, której używasz do opracowania), indywidualne zwężenia lub ostrzeżenia mogą być wyłączone leksykalnie. Co więcej, ich błędy mogą zostać uwięzione za pomocą eval{ .... }, z blokami try/catch o wartości Try::Tiny i kilkoma innymi sposobami. Jeśli pojawi się obawa związana z informacją potencjalnego napastnika o więcej informacji o skrypcie, wiadomości mogą zostać przekierowane do pliku dziennika. Jeśli istnieje ryzyko, że wspomniany plik dziennika zużyje dużo miejsca, istnieje większy problem, a źródło problemu powinno zostać rozwiązane lub w rzadkich przypadkach po prostu komunikat jest wyłączony.

Obecnie programy Perl powinny być bardzo surowe/ostrzeżenia zgodne z najlepszą praktyką.

Answer 2

Obie, oczywiście. Jeśli perl zostały zaprojektowane dzisiaj, używaj ostro i używaj ostrzeżeń, które będą domyślnym zachowaniem. To tak, jakby włączono ostrzeżenia w kompilatorze - dlaczego domyślnie nie zrobiłbyś tego?

Answer 3

Użyj obu, jak mówi strona z linkami.

Dokumentacja może być nieco niejasna. use strict i use warnings łapać różne problemy; będzie nie spowodować, że program zostanie natychmiast zamknięty po napotkaniu zwykłych ostrzeżeń, tylko wtedy, gdy naruszone zostaną ścisłe wymagania dotyczące składni. Nadal będziesz otrzymywać ostrzeżenia tylko wtedy, gdy twój kod będzie robił rzeczy, które są mniej poważne.

Answer 4

use strict; 
#use warnings; 
use diagnostics; # "This module extends the terse diagnostics..." by http://perldoc.perl.org/diagnostics.html 

Obie! Ale wolę diagnostykę zamiast ostrzeżeń, które dają ci więcej informacji.

Answer 5

To, co masz, nie wystarcza.

Używam kodu przybliżającego to jako punkt wyjścia. Działa dobrze w moim środowisku, chociaż jak zawsze twój przebieg może się różnić.

#!/usr/bin/env perl 

use v5.12; 
use utf8; 
use strict; 
use autodie; 
use warnings; 
use warnings qw< FATAL utf8  >; 
use feature  qw<unicode_strings>; 
use open  qw< :std :utf8  >; 
use charnames qw< :full   >; 

# These are core modules: 
use Carp    qw< carp croak confess cluck >; 
use File::Basename  qw< basename  dirname >; 
use Unicode::Normalize qw< NFD NFKD  NFC NFKC >; 
use Getopt::Long  qw< GetOptions    >; 
use Pod::Usage   qw< pod2usage    >; 

our $VERSION = v0.0.1; 

$0 = basename($0); # shorter messages 
## $| = 1; 

$SIG{__DIE__} = sub { 
    confess "Uncaught exception: @_" unless $^S; 
}; 

$SIG{__WARN__} = sub { 
    if ($^S) { cluck "Trapped warning: @_" } 
    else  { confess "Deadly warning: @_" } 
}; 

END { 
    local $SIG{PIPE} = sub { exit }; 
    close STDOUT; 
} 

if (grep /\P{ASCII}/ => @ARGV) { 
    @ARGV = map { decode("UTF-8", $_) } @ARGV; 
} 

binmode(DATA, ":utf8"); 

## Getopt::Long::Configure qw[ bundling auto_version ]; 

if (!@ARGV && -t STDIN) { 
    print STDERR "$0: reading from stdin: type ^D to end, ^C to kill...\n"; 
} 

while (<>) { 
    $_ = NFD($_); 
    # ... 
    print NFC($_); 
} 

exit; 

=pod 

=encoding utf8 

=head1 NAME 

=head1 SYNOPSIS 

=head1 DESCRIPTION 

=head1 OPTIONS 

=head1 EXAMPLES 

=head1 ERRORS 

=head1 FILES 

=head1 ENVIRONMENT 

=head1 PROGRAMS 

=head1 AUTHOR 

=head1 COPYRIGHT AND LICENCE 

=head1 REVISION HISTORY 

=head1 BUGS 

=head1 TODO 

=head1 SEE ALSO 

=cut 

__END__ 

Your UTF-8 data goes here. 

Można znaleźć więcej przykładów tego rodzaju rzeczy w akcji w Perl Unicode Tool Chest obecnie do około 50 plików, począwszy od prostych do wzniosłości.