arrays - ¿Son las últimas comas en Perl una mala práctica?
hash (5)
De hecho, es una buena práctica y también se menciona en el famoso PBP.
En realidad, hay una Política de perlcritic que siempre me atrapa: https://metacpan.org/pod/Perl::Critic::Policy::CodeLayout::RequireTrailingCommas
Hoy estuve en una reunión de Webex mostrando mi pantalla con un código de Perl que escribí. Mi jefe de repente me dijo que todos los demás estaban mirando y oyendo que tenía que eliminar las comillas finales de mis estructuras de matrices y hash porque es una mala práctica. Dije que no pensaba que fuera una mala práctica en Perl, pero insistió y me obligó a eliminar esas comas solo para mostrar mi secuencia de comandos ejecutándose en la reunión.
Todavía creo que no es una mala práctica en Perl, pero puedo estar equivocado. De hecho, los encuentro bastante cómodos y una buena práctica porque me impiden agregar nuevos elementos y olvidar agregar la coma correspondiente en el proceso.
Pero, realmente me gustaría saber si es una buena o mala práctica y poder mostrarle a mi jefe (si está equivocado) con buenos argumentos e incluso buenas fuentes para mis argumentos.
Entonces, ¿es una mala práctica dejar comas al final?
Esto es un ejemplo:
my $hash_ref = {
key1 => ''a'',
key2 => ''b'',
key3 => ''c'',
};
my $array_ref = [
1,
2,
3,
];
El documento de estilo de codificación mod_perl de Apache dice esto
Siempre que cree una lista o una matriz, siempre agregue una coma después del último elemento. La razón para hacer esto es que es muy probable que los artículos nuevos se anexen al final de la lista en el futuro. Si falta la coma y esto no se nota, habrá un error.
Lo que su gerente puede haber estado pensando es que hacer lo mismo en C no es estándar y no es portátil, sin embargo, no hay excusa para su comportamiento extraordinario.
Entonces, la página de PBP a la que se refiere Miller argumenta que es más fácil reordenar la lista cortando y pegando líneas; el documento de estilo de codificación mod_perl vinculado por Borodin defiende evitar un error de sintaxis momentáneo cuando agrega cosas.
Mucho más significativo que cualquiera, en mi opinión, es que si siempre tiene una coma al final y agrega una línea, la diferencia solo muestra la línea que agregó y las líneas existentes permanecen sin cambios. Esto hace que la búsqueda de culpa sea mejor y hace que las diferencias sean más legibles.
Es una gran práctica tener la coma final. Larry lo agregó debido a un error común que vio a los programadores. Cuando agregaban elementos a una lista (o lo llamaban su lenguaje), olvidaban el carácter separador. Perl permite la coma final a propósito. No es una rareza o efecto secundario de otra cosa.
Lo que es una mala práctica, sin embargo, es distraer una reunión llena de gente con algo que su jefe podría haber corregido más tarde. A menos que la reunión haya sido específicamente una revisión del código, su jefe perdió un montón de tiempo. Siempre deseé que para unirme a una videoconferencia, tuvieras que ingresar tu compensación por minuto para que se mostrara un contador en la pantalla de todo el mundo para mostrar cuánto dinero se estaba desperdiciando. Gastar un par de cientos de dólares viendo cómo eliminas las comas de un programa de trabajo aplacaría esas tonterías.
Yo prefiero las comas principales, aunque sé que es bastante impopular y parece irritar el disléxico. Tampoco he podido encontrar una opción perltidy para ello. También soluciona el problema del cambio de línea (a excepción de la primera línea, pero esa no suele ser la que cambia en mi experiencia), y adoro la forma en que las comas se alinean en columnas ordenadas. También funciona en idiomas que son agnósticos en espacios en blanco, pero no les gusta seguir comas en las listas de forma bastante clara. Creo que aprendí este patrón mientras trabajaba con javascript ...
my $hash_ref =
{ key1 => ''a''
, key2 => ''b''
, key3 => ''c''
};
my $array_ref =
[ 1
, 2
, 3
];