Perl - Estándar de codificación

Cada programador, por supuesto, tendrá sus propias preferencias con respecto al formato, pero hay algunas pautas generales que harán que sus programas sean más fáciles de leer, comprender y mantener.

Lo más importante es ejecutar sus programas bajo la bandera -w en todo momento. Puede desactivarlo explícitamente para partes particulares de código a través del pragma sin advertencias o la variable $ ^ W si es necesario. También debe ejecutar siempre bajo uso estricto o conocer la razón por la cual no. El uso de sigtrap e incluso el uso de pragmas de diagnóstico también pueden resultar útiles.

Con respecto a la estética del diseño del código, lo único que le importa mucho a Larry es que el corchete de cierre de un BLOQUE de varias líneas debe alinearse con la palabra clave que inició la construcción. Más allá de eso, tiene otras preferencias que no son tan fuertes:

  • Sangría de 4 columnas.
  • Apertura rizada en la misma línea que la palabra clave, si es posible, de lo contrario, alinee.
  • Espacio antes de la apertura rizada de un BLOQUE de varias líneas.
  • El BLOQUE de una línea se puede poner en una línea, incluidos los rizos.
  • Sin espacio antes del punto y coma.
  • Punto y coma omitido en BLOQUE "corto" de una línea.
  • Espacio alrededor de la mayoría de los operadores.
  • Espacio alrededor de un subíndice "complejo" (entre paréntesis).
  • Líneas en blanco entre trozos que hacen cosas diferentes.
  • Elses sin abrazar.
  • No hay espacio entre el nombre de la función y su paréntesis de apertura.
  • Espacio después de cada coma.
  • Líneas largas quebradas después de un operador (excepto yo).
  • Espacio después del último paréntesis que coincide con la línea actual.
  • Alinee los elementos correspondientes verticalmente.
  • Omita la puntuación redundante siempre que no se vea afectada la claridad.

Aquí hay algunos otros temas de estilo más importantes en los que pensar: El hecho de que PUEDA hacer algo de una manera en particular no significa que DEBE hacerlo de esa manera. Perl está diseñado para brindarle varias formas de hacer cualquier cosa, así que considere elegir la más legible. Por ejemplo

open(FOO,$foo) || die "Can't open $foo: $!";

Es mejor que ...

die "Can't open $foo: $!" unless open(FOO,$foo);

Porque la segunda forma esconde el punto principal de la declaración en un modificador. Por otra parte,

print "Starting analysis\n" if $verbose;

Es mejor que ...

$verbose && print "Starting analysis\n";

Porque el punto principal no es si el usuario escribió -v o no.

No hagas contorsiones tontas para salir de un bucle en la parte superior o inferior, cuando Perl proporciona el último operador para que puedas salir por el medio. Simplemente "anule un poco" para que sea más visible.

LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}

Veamos algunos puntos más importantes:

  • No tenga miedo de usar etiquetas de bucle: están ahí para mejorar la legibilidad y para permitir interrupciones de bucle de varios niveles. Vea el ejemplo anterior.

  • Evite el uso de grep () (o map ()) o `backticks` en un contexto vacío, es decir, cuando simplemente desecha sus valores de retorno. Todas esas funciones tienen valores de retorno, así que úselas. De lo contrario, use un bucle foreach () o la función system () en su lugar.

  • Para la portabilidad, cuando use características que pueden no estar implementadas en todas las máquinas, pruebe la construcción en una evaluación para ver si falla. Si sabe qué versión o nivel de parche se implementó una característica en particular, puede probar $] ($ PERL_VERSION en inglés) para ver si estará allí. El módulo de configuración también le permitirá interrogar los valores determinados por el programa Configurar cuando se instaló Perl.

  • Elija identificadores mnemónicos. Si no recuerda qué significa mnemotécnico, tiene un problema.

  • Si bien los identificadores cortos como $ gotit probablemente estén bien, use guiones bajos para separar palabras en identificadores más largos. Generalmente, es más fácil leer $ var_names_like_this que $ VarNamesLikeThis, especialmente para hablantes no nativos de inglés. También es una regla simple que funciona de manera coherente con VAR_NAMES_LIKE_THIS.

  • A veces, los nombres de los paquetes son una excepción a esta regla. Perl reserva informalmente nombres de módulos en minúsculas para módulos "pragma" como integer y estricto. Otros módulos deben comenzar con una letra mayúscula y usar mayúsculas y minúsculas, pero probablemente sin guiones bajos debido a las limitaciones en las representaciones de los sistemas de archivos primitivos de los nombres de los módulos como archivos que deben caber en unos pocos bytes dispersos.

  • Si tiene una expresión regular muy peluda, use el modificador / x y ponga algunos espacios en blanco para que se vea un poco menos como ruido de línea. No utilice barra inclinada como delimitador cuando su expresión regular tiene barras inclinadas o barras invertidas.

  • Siempre verifique los códigos de retorno de las llamadas al sistema. Los buenos mensajes de error deben ir a STDERR, incluir qué programa causó el problema, cuáles fueron la llamada al sistema fallida y los argumentos, y (MUY IMPORTANTE) deben contener el mensaje de error estándar del sistema para lo que salió mal. Aquí hay un ejemplo simple pero suficiente:

opendir(D, $dir) or die "can't opendir $dir: $!";

  • Piense en la reutilización. ¿Por qué desperdiciar la capacidad intelectual en una sola oportunidad cuando es posible que desee hacer algo así de nuevo? Considere generalizar su código. Considere escribir un módulo o una clase de objeto. Considere hacer que su código se ejecute limpiamente con use estricto y use advertencias (o -w) en efecto. Considere regalar su código. Considere cambiar toda su visión del mundo. Considere ... oh, no importa.

  • Se consistente.

  • Se bueno.