Lo que hace que el código Perl mantenible?

StackOverflow https://stackoverflow.com/questions/4349142

  •  30-09-2019
  •  | 
  •  

Pregunta

He escrito en Perl desde hace varios años y es mi idioma preferido para el procesamiento de textos (muchos de los problemas de genética / genómica en los que trabajo se reducen fácilmente a problemas de procesamiento de texto). Perl como lenguaje puede ser muy indulgente, y es posible escribir muy pobre, pero funcional, el código en Perl. Justo el otro día, mi amigo dijo que él llama Perl un de sólo escritura idioma:. Escribir una vez, comprender una vez, y nunca jamás tratar de volver atrás y fijarlo después de que haya terminado

Mientras que definitivamente he sido culpable de escribir guiones malos, a veces, me siento como también he escrito algo de código muy clara y fácil de mantener en Perl. Sin embargo, si alguien me preguntó qué hace el código clara y fácil de mantener, yo no sería capaz de dar una respuesta segura.

Lo que hace mantenible código Perl? O tal vez una mejor pregunta es lo que hace que el código Perl difícil de mantener? Vamos a suponer que no soy el único que se mantiene el código, y que los otros colaboradores, como yo, son los programadores no profesionales Perl, pero los científicos con experiencia en programación.

¿Fue útil?

Solución

Lo que hace que el código Perl imposible de mantener? Casi cualquier cosa que hace imposible de mantener cualquier otro programa. Suponiendo que no sea un pequeño script prevista la realización de una tarea bien definida nada, estos son:

  • Las variables globales
  • falta de separación de las preocupaciones: guiones monolíticos
  • NO usando identificadores de auto-documentado (nombres de variables y nombres de los métodos). P.ej. usted debe saber lo que el propósito de una variable es de su nombre. $c mal. $count mejor. buena $token_count.
    • Hechizo identificadores a cabo. El tamaño del programa ya no es una preocupación primordial.
    • Una subrutina o método llamado doWork no dice nada
    • Que sea fácil de encontrar la fuente de símbolos de otro paquete. O bien utilizar el prefijo paquete explícito, o explícitamente importar cada símbolo que se utiliza a través de use MyModule qw(list of imports).
  • Perl-específica:
    • La excesiva dependencia de los atajos y variables incorporadas oscuras
    • Abuso de subrutina prototipos
    • No utilizar strict y no usar warnings
  • reinventar la rueda en lugar de utilizando bibliotecas establecidas
  • No usar un estilo de sangría constante
  • No utilizar el espacio en blanco horizontal y vertical para guiar al lector

etc, etc, etc.

Básicamente, si usted piensa Perl es -f>@+?*<.-&'_:$#/%! , y que aspiran a cosas como esa escritura en el código de producción, entonces, sí, tendrá problemas.

La gente tiende a confundir los programadores de Perl cosas hacer para divertirse (por ejemplo, JAPHs, golf, etc.), con lo que los buenos programas de Perl se supone que parecen.

Estoy todavía no está claro en la forma en que son capaces de separar en sus mentes código escrito para IOCCC de C de mantener.

Otros consejos

Sugiero:

  1. No demasiado inteligente con el Perl. Si usted comienza a jugar al golf con el código, que va a dar lugar a código más difícil de leer. El código que escriba necesidades sea legible y clara más de lo que tiene que ser inteligente.
  2. Documento del código. Si se trata de un módulo, añadir POD que describe el uso y los métodos típicos. Si se trata de un programa, añadir POD para describir las opciones de línea de comandos y el uso típico. Si hay un algoritmo cabelludo, documentos y proporcionar referencias (URL) si es posible.
  3. Utilice el formulario /.../x de las expresiones regulares, y el documento de ellas. No todo el mundo entiende expresiones regulares también.
  4. Saber qué es el acoplamiento, y las ventajas / desventajas de alta acoplamiento / baja.
  5. Saber qué es la cohesión, y las ventajas / desventajas de alta / baja cohesión.
  6. utilizar módulos apropiadamente. Una bonita bien definido, el concepto bien contenida hace un gran módulo. La reutilización de estos módulos es la meta. No utilice módulos simplemente para reducir el tamaño de un programa monolítico.
  7. pruebas de la unidad de escritura para que el código. Un buen conjunto de pruebas no sólo le permitirá probar su código está trabajando hoy, pero mañana también. También le permitirá hacer cambios audaces en el futuro, con la confianza de que usted no está rompiendo las aplicaciones más antiguas. Si haces las cosas se rompen, entonces, bueno, su suite de pruebas no era lo suficientemente amplia.

Pero, en general, el hecho de que usted se preocupa lo suficiente sobre mantenimiento a preguntar algo sobre él, me dice que ya se encuentra en un lugar bueno y pensar de la manera correcta.

Yo no uso todos Perl Best Practices , pero esa es la cosa que Damian escribió para. Sea o no que todo el uso de las sugerencias, que son todos vale la pena al menos teniendo en cuenta.

  

Lo que hace que el código Perl mantenible?

Al menos: 

use strict;
use warnings;

perldoc perlstyle para algunas pautas generales que harán que sus programas sean más fáciles de leer, comprender, y mantener.

Un factor muy importante a la legibilidad del código que no he visto mencionado en otras respuestas es la importancia del espacio en blanco, que es a la vez Perl-agnóstico y en cierto modo Perl-específica.

Perl le permite escribir código muy concisa, pero trozos Consise no significa que tengan que ser todos agrupados juntos.

El espacio en blanco tiene un montón de significado / usos cuando estamos hablando de la legibilidad, no todos ellos ampliamente utilizado, pero más útil:

  • Los espacios alrededor tokens, hasta más fácil separar visualmente.

    Este espacio es doblemente importante en Perl debido a la prevalencia de caracteres ruido en la línea, incluso en el mejor estilo de código Perl.

    Me parece $myHashRef->{$keys1[$i]}{$keys3{$k}} sea menos legible a las 2 de la mitad de emergencia producion en comparación con espaciados: $myHashRef->{ $keys1[$i] }->{ $keys3{$k} }.

    Como nota al margen, si usted encuentra su código haciendo una gran cantidad de expresiones de referencia anidados de profundidad todo a partir de la misma raíz, debe absolutamente considerar la asignación de esa raíz en un puntero temporal (véase el comentario / respuesta de Sinan).

    Un caso especial parcial, pero muy importante de esto es, por supuesto, las expresiones regulares. La diferencia se ilustra a muerte en todos los principales materiales que recuerdo (PBP, RegEx libro de O'Reilly, etc ..) así que no alargar este post aún más a no ser que alguien ejemplos peticiones en los comentarios.

  • correcta y uniforme de indentación. D'oh. Obviamente. Sin embargo, veo demasiado código 100% debido a la penetración ilegible basura, e incluso menos legible cuando la mitad del código fue una sangría con las tabulaciones por una persona cuyo editor usado 4 fichas de personajes y de otra por una persona cuyo editor utilizado 8 tabulaciones de caracteres. Sólo hay que establecer su editor sangrienta hacer blandos (por ejemplo, el espacio emulado) OET, ya no hacen otras desgraciadas.

  • Las líneas vacías alrededor de las unidades lógicamente independientes de código (ambos bloques y conjuntos de sólo líneas). Se puede escribir un programa Java 10000 línea en 1000 líneas de buena Perl. Ahora no se siente como Benedict Arnold si se agrega 100-200 líneas vacías a los 1000 para hacer las cosas más fácil de leer.

  • Las expresiones súper-larga división en múltiples líneas, seguidos de cerca por ...

  • alineación vertical correcta. Sea testigo de la diferencia entre: 

    if ($some_variable > 11 && ($some_other_bigexpression < $another_variable || $my_flag eq "Y") && $this_is_too_bloody_wide == 1 && $ace > my_func() && $another_answer == 42 && $pi == 3) {

    y 

    if ($some_variable > 11 && ($some_other_bigexpression < $another_variable || 
    $my_flag eq "Y") && $this_is_too_bloody_wide == 1 && $ace > my_func()
    && $another_answer == 42 && $pi == 3) {

    y 

    if (   $some_variable > 11
    && ($some_other_bigexpression < $another_variable || $my_flag eq "Y")
    && $this_is_too_bloody_wide == 1
    && $ace > my_func()
    && $another_answer == 42
    && $pi == 3) {

    En lo personal, prefiero fijar la alineación vertical un paso más mediante la alineación de LHS y RHS (esto es especialmente legible en el caso de las consultas SQL largas sino también en sí mismo código Perl, tanto los largos condicionales como éste, así como muchas líneas de las tareas y las inicializaciones de hash / matriz): 

    if (   $some_variable               >  11
    && ($some_other_bigexpression   <  $another_variable || $my_flag eq "Y")
    && $this_is_too_bloody_wide    ==  1
    && $ace                         >  my_func()
    && $another_answer             ==  42
    && $pi                         ==  3  ) {

    Como nota al margen, en algunos casos, el código podría ser aún más legible / mantenible por no tener este tipo de expresiones largas en el primer lugar. P.ej. Si el contenido del bloque de if(){} es un return, a continuación, hacer múltiples declaraciones if/unless cada uno de los cuales tiene un bloque de retorno puede ser mejor.

i ver esto como un problema de las personas que nos digan que Perl es ilegible, y empiezan a hacer suposiciones sobre la maintability de su propio código. si está lo suficientemente consciente para considerar la lectura como un sello de código de calidad, lo más probable es que esta crítica no se aplica a usted.

mayoría de la gente citar expresiones regulares cuando discuten la legibilidad. expresiones regulares son una DSL incrustado en Perl y que cualquiera puede leerlos o no. si alguien no puede tomar el tiempo para entender algo tan básico y esencial para muchos idiomas, no estoy preocupado por tratar de salvar algunos brecha cognitiva inferido ... que sólo debe al hombre, lea las perldocs, y hacer preguntas cuando sea necesario .

otros citar el uso de formato corto de Perl vars como @_, $! etc Estas son desambiguadas fácilmente ... No estoy interesado en hacer mirada Perl como Java.

al alza de todas estas peculiaridades y perlisms es que las bases de código escritas en el lenguaje suelen ser conciso y compacto. Prefiero leer las líneas de Perl diez de cien líneas de Java.

para mí no es mucho más que "de mantenimiento" que simplemente tener fácil de lectura de código. pruebas de escritura, las afirmaciones de marca ... y hacer todo lo que puede hacer para apoyarse en Perl y su ecosistema para mantener código correcto.

En pocas palabras:. Programas de escritura para ser el primero correcta, a continuación, fije, a continuación, de buen rendimiento .... una vez que estos objetivos se han cumplido, entonces se preocupe por lo que es agradable para acurrucarse con cerca de un fuego

Yo diría que los modelos de embalaje / objeto, que se refleja en la estructura de directorios de archivos .pm. Para mi doctorado he escrito un buen montón de código Perl que reutilizar después. Fue por generador diagrama LaTeX automático.

Voy a hablar algunos positivos cosas para hacer Perl mantenible.

Es cierto que por lo general no debe ser demasiado inteligente con declaraciones muy densas a la return !$@;#% y similares, pero una buena cantidad de inteligentes que utilizan los operadores de la lista de procesamiento, como map y vuelve grep y la lista de contexto de la talla de split y operadores similares, con el fin de escribir código en un estilo funcional pueden hacer una contribución positiva a la capacidad de mantenimiento. En mi último empleador también tuvimos algunas funciones de hash de manipulación elegantes que funcionaban de manera similar (hashmap y hashgrep, aunque técnicamente sólo les listas de tamaño uniforme Fed). Por ejemplo: 

# Look for all the servers, and return them in a pipe-separated string
# (because we want this for some lame reason or another)
return join '|', 
       sort
       hashmap {$a =~ /^server_/ ? $b : +()} 
       %configuration_hash;

Véase también orden superior Perl , http://hop.perl.plover.com -. buen uso de metaprogramming puede hacer que la definición de las tareas más coherente y legible, si se puede mantener la metaprogramming sí mismo de entrar en el camino

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top