2011-06-18 16 views
8

¿Cuál safety net usas?¿Qué red de seguridad usas en Perl?

usa advertencias;

o

uso estricto;

sé que

Un problema potencial capturado por el uso estricta; hará que su código se detenga inmediatamente cuando se encuentre, mientras usa advertencias; simplemente dará una advertencia (como el modificador de línea de comandos -w) y permitirá que se ejecute su código.

Todavía quiero saber cuál es el más utilizado por los programadores Perl. ¿Cuál han visto que se usa más?

+0

Motivo de la votación cercana? –

+2

No voté para cerrar, pero sospecho que es porque las advertencias y estrictas hacen cosas completamente diferentes. No es una pregunta de ambos, usa ambos. –

+0

Gracias por las ediciones. [@starblue: para editar el título y @tchrist para agregar etiquetas adicionales] –

Respuesta

13

use strict genera un error si utiliza referencias simbólicas (es decir, cadenas para representar nombres de símbolos). Genera un error si usa una variable sin declararla (esto fomenta el uso de variables léxicas 'my', pero también se cumple si declara correctamente los paquetes globales). También genera un error si deja palabras sin usar en la secuencia de comandos (cadenas sin comillas, esencialmente, según la definición de citas de Perl). Con 'strict', puede habilitar o deshabilitar cualquiera de las tres categorías de restricciones, y yo lo hago dentro de los bloques delimitados. Es una práctica recomendada habilitar restricciones, aunque en ocasiones el código legítimo requiere que algunas de sus características se deshabiliten localmente. Sin embargo, uno debería pensar detenidamente si esto es realmente necesario y si su solución es ideal. Puede leer sobre las restricciones en el POD de Perl titulado "estricto".

use warnings genera un mensaje de advertencia basado en muchos criterios, que se describen en el POD 'perllexwarn'. Estas advertencias no tienen nada que ver con las restricciones, sino que buscan los "errores" más comunes que uno probablemente encuentre en su programación. También es una buena práctica usar advertencias al escribir scripts. En algunos casos en los que el mensaje puede ser indeseable, una determinada categoría de advertencia puede desactivarse localmente dentro de un alcance. Información adicional se describe en 'advertencias'.

use diagnostics hace que las advertencias sean más detalladas, y en un entorno de desarrollo o aprendizaje, especialmente entre los recién llegados, es muy deseable. Los diagnósticos probablemente quedarían fuera de un 'producto final', pero mientras están en desarrollo pueden ser una buena adición a los mensajes claros que normalmente se generan. Puede leer sobre diagnósticos en el "diagnóstico" Perl POD.

No hay ninguna razón para obligarse a usar solo una de las opciones anteriores u otra. En particular, las advertencias de uso y el uso estricto generalmente se deben usar en los programas modernos de Perl.

En todos los casos (excepto los diagnósticos, que solo está utilizando para el desarrollo de todos modos), las restricciones o advertencias individuales pueden estar deshabilitadas léxicamente. Además, sus errores pueden quedar atrapados en eval{ .... }, con los bloques try/catch de Try::Tiny, y en algunas otras formas. Si existe una preocupación acerca de un mensaje que ofrezca a un posible atacante más información sobre un script, los mensajes podrían enrutarse a un archivo de registro. Si existe el riesgo de que dicho archivo de registro consuma mucho espacio, existe un problema mayor, y el origen del problema debería resolverse o, en algunos casos, simplemente tener el mensaje deshabilitado.

Los programas de Perl en la actualidad deberían ser altamente estrictos/cumplir con las advertencias como una buena práctica.

+0

Bien explicado. +1 Gracias :) –

20

Ambos, por supuesto. Si perl se diseñó hoy, use estrictas y las advertencias de uso serían el comportamiento predeterminado. Es como tener activadas las advertencias en un compilador, ¿por qué no harías eso por defecto?

+0

Es como tener activadas las advertencias en un compilador. +1 Gracias :) –

+1

'no strict;' sería malo para code golf? :) – geoffspear

11

Use ambos, como dice la página enlazada.

La documentación es tal vez un poco confusa. use strict y use warnings atrapan diferentes problemas; use strictno hace que su programa salga inmediatamente cuando se producen meras advertencias, solo cuando viola los estrictos requisitos de sintaxis. Seguirá recibiendo solo advertencias cuando su código haga cosas que sean menos graves.

+0

use strict no hará que su programa salga inmediatamente cuando se encuentren advertencias. Gracias por proporcionar esta información :) +1 –

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

Both! Pero prefiero los diagnósticos, en lugar de las advertencias, que le dan más información.

+1

¿Hay algún problema con el diagnóstico? ¡Recibo algunos comentarios negativos con esta respuesta! – cirne100

+2

Esa es una buena pregunta, gracias :) +1 –

+6

diagnóstico probablemente sería excesivo para los propósitos del OP (una red de seguridad), pero esa no es realmente una razón para rechazarlo. – ikegami

14

Lo que tienes ni siquiera empieza a ser suficiente.

Utilizo el código aproximándolo como punto de partida. Funciona bien en mi entorno, aunque como siempre su kilometraje puede variar.

#!/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 ([email protected] && -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. 

Puede encontrar más ejemplos de este tipo de cosas en acción en el Perl Unicode Tool Chest, actualmente hasta alrededor de 50 archivos que van de lo simple a lo sublime.

+2

Por supuesto, esta es la respuesta que debería obtener todos los votos por arriba. :) La única advertencia que puedo sugerir es leer y aprender por qué Tom usa cada una de estas herramientas en lugar de simplemente cortar y pegar a ciegas. No puedo decir que los entiendo a todos, así que también me da algo para sumergirme. – DavidO

+0

¿Existe alguna razón para la presencia de 'use v5.12;' y 'use strict;'? Pensé 'use strict;' estaba implícito en 'use v5.12;'. –

+0

Bueno, una razón podría ser para el beneficio de los lectores con menos conocimiento. No he usado Perl por encima de 5.10, ¡así que ni siquiera estaba al tanto de esa característica en 5.12! – Dan

Cuestiones relacionadas