2012-07-20 12 views
8

Estoy usando el siguiente comando para probar mi código perl:¿Hay algún módulo que me falte para ayudarme a escribir un código mejor?

perl -MB :: Lint :: StrictOO -MO = Lint, all, oo -M-circular :: require -M-indirect-advertencias: : method -Mwarnings :: inusitado -c $ file

En un sistema con una versión perl de menos de 5.10 también estoy usando uninit.

También estoy usando Perl :: Critic y Perl :: Tidy y he configurado los archivos rc apropiados a mi gusto.

Estos módulos han hecho un gran trabajo al ayudarme a romper algunos malos hábitos que aprendí cuando aprendí perl por primera vez.

¿Hay más módulos o pragmas que me devuelvan a la normalidad cuando lo estropeo?

Usando pruebas, y la familia de módulos Test :: * y algunos buenos libros han sido señalados. Esta nueva información me ha llevado a reconsiderar algunas suposiciones sobre la relación entre las pruebas y el desarrollo de habilidades del código. Todos son apreciados y ya están siendo investigados y puestos en uso.

Me parece que estas son dos partes separadas de un todo. 'perl -c', Perl :: Critic y Perl :: Tidy ayudan durante el proceso de escritura del código y antes de la ejecución del código. Devel :: Cover, Devel :: NYTProf y las pruebas suceden durante y después de la ejecución del código.

El buen desarrollo dicta un proceso iterativo, por lo que las pruebas se ejecutarán y el código se desarrollará una y otra vez, pero aún tenemos esta separación.

Me parece que el foco en las respuestas ha estado en el 'durante y después de la ejecución' del código. De nuevo, esto es muy apreciado. ¿Puedo asumir que tengo la parte de 'escritura y pre-ejecución' bastante bien entonces? Al menos, en lo que concierne a los pragmas, módulos y utilidades.

+2

Puede que sea hora de aprender a moverse Prueba :: Más si aún no lo ha hecho. Entrenarse para escribir pruebas antes de su código objetivo lo alentará a codificar en trozos más pequeños, más manejables y, a menudo, más generales. Y probar su código tiene que conducir a un mejor código, si una definición de mejor es menos problemática. Muchos de los módulos Test :: * proporcionan controles adicionales sin mucho esfuerzo. – DavidO

+0

Uso mucho la serie de módulos Test :: ... No había considerado las pruebas como una forma de mejorar mis habilidades de codificación. Utilizo DistZilla siempre que sea posible y eso hace que el uso de pruebas sea muy fácil, lo cual aprovecho. Parece que tengo que volver atrás y comenzar a evaluar los módulos Test :: bajo una nueva luz. – harleypig

+0

También hay algunos libros realmente buenos por ahí. Perl de orden superior Perl moderno. (Ambos están disponibles en línea gratis, legítimamente.) Hay muchos otros, pero esos dos son buenos libros para aprender un acercamiento iluminado a Perl. – DavidO

Respuesta

4

Estoy un poco preocupado de que estés usando Perl 5.9. Por dos razones.

En primer lugar, es un poco viejo. 5.9.0 fue lanzado en 2003 y 5.9.5 (la última versión en la serie 5.9.x) fue lanzado en 2007. Ha habido varias versiones de alta calidad de Perl desde entonces.

En segundo lugar (y lo más importante), 5.9 es una versión de desarrollo inestable de Perl. 5.9 es básicamente la serie de experimentos que eventualmente llevaron a Perl 5.10.0. La única razón para usarlo es probar que 5.10 será una versión estable de Perl. Nadie debería usarlo ahora.

+0

:] Estoy de acuerdo, nadie * debería * estar usando nada menos que 5.10 ... probablemente incluso 5.14 ... sin embargo, lo que debería ser y lo que es generalmente son dos cosas diferentes. Trabajo en código heredado mucho. Algunos de los servidores en los que trabajo todavía usan 5.004. – harleypig

+0

Derecha. Puedo (simplemente) entender por qué podrías estar usando una versión dolorosamente antigua de Perl. Pero no puedo entender por qué estarías usando una versión de desarrollo inestable. –

+0

Mis disculpas ... No uso 5.9 en ninguna parte de la que tenga conocimiento ... cuando investigué por qué uninit fallaba en una caja con 5.14 descubrí que la eliminación de no iniciada se había eliminado en 5.10. El código que genera el comando busca '$] <5.010', así que tiendo a pensar 'cualquier cosa 5.9 y menos'. Perdón por la confusión sobre eso. – harleypig

2

Parece que no está probando su código, simplemente comprobando que compilará. Sugiero que veas Test :: More (que hace que escribir pruebas reales sea agradable y fácil), Test :: Class (que facilita el manejo de suites de prueba muy grandes) y Devel :: Cover (para ver qué partes de tu código están cubiertos por sus pruebas y cuáles no).

+0

Estoy probando mi código siempre que sea posible. Simplemente no lo había considerado como parte de mejorar mis habilidades de codificación. Estaré mirando la familia de módulos Test :: con una luz diferente ahora. – harleypig

+0

Diría que si alguna vez es imposible probar tu código (lo que implica que pruebas siempre que sea posible), entonces debes volver a escribirlo para * hacer * que sea posible. Me doy cuenta de que esto no siempre es práctico, por ejemplo, si estás hablando con algunos servicios externos, pero es algo que siempre debes tratar de hacer. Si tiene que tratar con una interfaz externa no comprobable, entonces considere separar el código para que se relacione con él desde el resto de la aplicación, de modo que pueda simular esa interfaz y al menos probar tanto como sea posible. Y realmente debería mirar Devel :: Cover. Me ha salvado mi trabajo en el pasado. – DrHyde

Cuestiones relacionadas