Captura de errores en los lenguajes de script

Question

Si el lenguaje de scripting de su elección no tiene algo como el modo strict de Perl, ¿cómo está captando errores tipográficos? ¿Estás haciendo pruebas unitarias de todo? Cada constructor, cada método? ¿Es esta la única manera de hacerlo?

Answer 1

Pruebas de unidad realmente minuciosas son la técnica más importante (sí, siempre intento alcanzar el 100% de cobertura), ya que también detectan muchos otros errores (por ejemplo, donde escribo + y significa -), uno a uno problemas, etc. Las pruebas de integración y carga que ejercen cada característica son la segunda línea de defensa contra todo tipo de errores (en su mayoría, más profundos y más difíciles ;-).

Las siguientes son herramientas como pylint y pychecker y editores de color (no uso IDEs reales, pero también me ayudarían de manera similar a como lo hace mi fiel editor de gvim ;-).

Técnicas tales como las revisiones obligatorias de código (por ejemplo, cfr un video de una entrevista mía sobre el tema here), si bien es crucial, deben centrarse en otros problemas - problemas que las herramientas automatizadas simplemente no lo hará captura , tales como integridad y exactitud de comentarios/cadenas de documentación, selección de buenos algoritmos/rápidas, y similares (ver here para un resumen de la charla que di sobre el tema en la misma conferencia como llegué a la entrevista a, y un enlace a el PDF de las diapositivas).

Answer 2

Existen errores que no son "errores tipográficos". Si no prueba algo, saber que algo ha encontrado nombres de variables mal escritos no le asegurará mucho de todos modos.

Answer 3

Algunos editores (por ejemplo, NetBeans) analizan su código y subrayan las partes "sospechosas", por ejemplo, variables no utilizadas, que pueden ser señal de un error tipográfico. NB también resalta el identificador sobre el cursor en otra parte de la pantalla, lo que también ayuda.

Por supuesto, ningún truco de IDE inteligente puede reemplazar las pruebas adecuadas.

Answer 4

TDD - primero escriba sus pruebas, luego el código más simple para pasar la prueba. De esta forma, puede estar más seguro de que no tiene ningún código no probado. Esto le ayudará a asegurarse de tener menos errores tipográficos u otros errores en su código.

Revisiones de programación/código de par: dos pares de ojos son mejores que un par.

IDE con intellisense - no es una panacea, pero una gran ayuda para no hacer errores tipográficos. Si usas intellisense, normalmente obtienes errores de sustitución, no errores tipográficos. Esto no debería ser difícil de encontrar con las pruebas.

Answer 5

Muchas herramientas de prueba de unidades pueden mostrar el porcentaje de líneas que probaron. Cuanto más cerca esté este porcentaje del 100%, menos probable será el error de nombre de la variable.

Answer 6

Escribo todos mis códigos Python en eclipse IDE. Como ha sugerido Mladen Jablanović, el eclipse subraya las partes sospechosas.

El siguiente paso es ejecutar el código. Ahora hay dos tipos de errores que probablemente enfrentaré.

1. Los errores que las capturas de intérprete y me da un número de línea para: Por lo general son bastante fáciles de depurar, especialmente si imprime todas las variables en esa línea justo antes de esa línea, para asegurarse de que contienen la valores que esperarías

2. Comportamiento inesperado: su código es correcto y el intérprete no se queja, pero su código no se comporta de la manera que usted desea. Cuando esto sucede (rara vez, porque generalmente diseño mis módulos bastante bien, un proceso que toma alrededor de 7 minutos, antes de comenzar a codificar) empiezo a buscar módulos/funciones en el orden en el que se llaman y trato de ejecutar el programa en mi cabeza como el intérprete lo vería. Si eso no funciona, entonces voy a explorar el depurador. Por lo general, no se reduce a esto, pero si lo hace, es un error bastante grande y tomaría bastante tiempo arreglarlo. Las pruebas unitarias ayudan, pero francamente, creo que como científico informático, debería poder depurarlo desde la perspectiva del análisis de algoritmos, que generalmente es más rápido que la prueba unitaria (al menos para mí). Además, elegir hacer un análisis de algoritmos sobre pruebas unitarias ejercita mi cerebro para que no cometa esos errores en el futuro, en comparación con las pruebas unitarias que me ayudan a solucionar el problema ahora, pero no ayuda mucho en términos de ayudar evito cometer el mismo error/similar en el futuro.

Esperanza esto ayuda

Answer 7

En Ruby, una variable local mal escrito haría que el programa para morir horriblemente, lo cual está bien.

Una variable de instancia mal escrita no hace que el programa muera horriblemente, lo que es malo. Para detectar tales casos, use warnings. Desafortunadamente, no se puede decir fácilmente Ruby al treat warnings as errors.

Answer 8

En mi caso, utilizo pruebas unitarias extensamente (desarrollándome en Python). Debido a que hay muchos marcos de pruebas de peso ligero y bien integrados a la lengua (o IDE, si lo prefiere), usándolos causa casi sin dolor;)

vistazo a este ejemplo:

def unpack_args(func): 
    def deco_func(*args): 
     if isinstance(args, tuple): 
      args = args[0] 

     return func(*args) 

    return deco_func 


def func1(*args): 
    """ 
    >>> func1(1,2,3) 
    (1, 2, 3) 
    >>> func1(*func2(1,2,3)) 
    (1, 2, 3) 
    >>> func1(func2(1,2,3)) 
    ((1, 2, 3),) 
    """ 
    return args 

def func2(*args): 
    """ 
    >>> func2(1,2,3) 
    (1, 2, 3) 
    """ 
    return args 

@unpack_args 
def func3(*args): 
    return args 


def test(): 
    """ 
    >>> func3(func2(1,2,3)) 
    (1, 2, 3) 
    """ 
    import doctest 
    doctest.testmod(verbose=True) 


test() 

    ----------------------------- 
    Results: 

Trying: 
    func1(1,2,3) 
Expecting: 
    (1, 2, 3) 
ok 
Trying: 
    func1(*func2(1,2,3)) 
Expecting: 
    (1, 2, 3) 
ok 
Trying: 
    func1(func2(1,2,3)) 
Expecting: 
    ((1, 2, 3),) 
ok 
Trying: 
    func2(1,2,3) 
Expecting: 
    (1, 2, 3) 
ok 
Trying: 
    func3(func2(1,2,3)) 
Expecting: 
    (1, 2, 3) 
ok 
3 items had no tests: 
    __main__ 
    __main__.func3 
    __main__.unpack_args 
3 items passed all tests: 
    3 tests in __main__.func1 
    1 tests in __main__.func2 
    1 tests in __main__.test 
5 tests in 6 items. 
5 passed and 0 failed. 
Test passed. 

Answer 9

supongo que por 'error tipográfico 'te refieres a escribir mal nombres de variable/función/clase. Esto es menos un problema en Python que en Perl, ya que Perl (y creo que Ruby) de forma predeterminada creará automáticamente una variable y la inicializará a cero o "" en su primer uso. Python no hace esto, ya que es un error utilizar una variable que no se ha creado explícitamente, por lo que en ese sentido ya está en modo 'estricto'.

Uso Vim con el complemento pyflakes, que subraya la mayoría de los tipos de errores tan pronto como los escribe. También uso frecuentemente pylint y pychecker ya que pueden detectar muchos otros tipos de errores.

Otra cosa que hago es hacer un uso intensivo de finalización automática de Vim - Sólo escriba un nombre en su totalidad una vez, a continuación, en los usos posteriores del nombre del tipo de las primeras letras y el uso de <ctrl-n> o <ctrl-p> para recorrer los partidos.

También uso Test Driven Development con el objetivo de obtener una cobertura de prueba 100% unitaria.

Me parece que la combinación de todas estas prácticas significa que los problemas causados ​​por errores tipográficos son prácticamente inexistentes.

Answer 10

En Groovy, el árbol de sintaxis abstracta (AST) que compone un programa está disponible. De modo que se pueden escribir herramientas que inspeccionen el AST y emitan advertencias para cosas que probablemente sean errores.

Por ejemplo, GroovyLint le advertirá si intenta llamar a un método que no existe en tiempo de compilación, pero está muy cerca de uno que sí existe.

Ejemplo:

class Test{ 
    static def foobar(){ return 5; } 
} 

Test.fooBar() //Here GroovyLint suggests calling foobar instead of fooBar.