Ловля опечаток в скриптовых языках - PullRequest
31 голосов
/ 21 марта 2010

Если у вашего языка сценариев нет ничего похожего на режим строгого в Perl, как вы ловите опечатки? Вы все юнит тестируете? Каждый конструктор, каждый метод? Это единственный способ сделать это?

Ответы [ 10 ]

33 голосов
/ 21 марта 2010

Действительно тщательные юнит-тесты являются наиболее важной техникой (да, я всегда стремлюсь к 100% охвату), так как они также улавливают много других опечаток (например, там, где я пишу + и имелось в виду -), вне отдельные проблемы и т. д. Интеграционные и нагрузочные тесты, выполняющие каждую функцию, являются второй линией защиты от всех видов ошибок (в основном, хотя и более глубоких и сложных; -).

Далее идут такие инструменты, как pylint и pychecker и редакторы для раскрашивания (я не использую настоящие IDE, но они также могут помочь аналогично тому, как это делает мой верный редактор gvim; - ).

Методы, такие как обязательные проверки кода (например, видео моего интервью на эту тему здесь ), хотя и имеют решающее значение, должны фокусироваться на других проблемах - проблемах, которые автоматизированные инструменты просто не будут замечать, такие как полнота и правильность комментариев / строк документации, выбор хороших / быстрых алгоритмов и т. п. (см. здесь для краткого изложения доклада I выступил по этому вопросу на той же конференции, на которой я давал это интервью, и дал ссылку на слайды в формате PDF).

3 голосов
/ 21 марта 2010

Некоторые редакторы (например, NetBeans) анализируют ваш код и подчеркивают «подозрительные» части, например неиспользуемые переменные, которые могут быть признаком опечатки. NB также выделяет идентификатор над курсором в другом месте экрана, что также помогает.

Конечно, ни один умный трюк IDE не может заменить правильное тестирование.

3 голосов
/ 21 марта 2010

Есть ошибки, отличные от "опечаток". Если вы что-то не тестируете, то, зная, что что-то найдено с именами переменных с орфографической ошибкой, вы в любом случае не будете уверены.

1 голос
/ 07 апреля 2010

Полагаю, под «опечаткой» вы подразумеваете опечатку имен переменных / функций / классов. Это меньше проблем в Python, чем в Perl, так как Perl (и я считаю, Ruby) по умолчанию автоматически создаст переменную и инициализирует ее нулем или "" при первом использовании. Python не делает этого, поскольку ошибочно использовать переменную, которая не была явно создана, поэтому в этом смысле она уже находится в «строгом» режиме.

Я использую Vim с плагином pyflakes , который подчеркивает большинство типов опечаток, как только вы их набираете. Я также часто использую Pylint и Pychecker, так как они могут ловить много других типов ошибок.

Еще одна вещь, которую я делаю, - это интенсивное использование автозаполнения Vim - я набираю имя полностью один раз, затем при последующих использованиях имени набираю первые несколько букв и использую <ctrl-n> или <ctrl-p> для циклического просмотра матчей.

Я также использую Test Driven Development с целью обеспечения 100% модульного тестирования.

Я считаю, что сочетание всех этих практик означает, что проблемы, вызванные опечатками, практически не существует.

1 голос
/ 07 апреля 2010

В моем случае я широко использую модульное тестирование (разработка на Python). Поскольку существует множество облегченных сред тестирования, хорошо интегрированных в язык (или IDE, если вы предпочитаете), их использование практически не причиняет вам боли;)

Посмотрите на этот пример:

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.
1 голос
/ 22 марта 2010

В ruby ​​локальная переменная с орфографическими ошибками может привести к ужасной гибели программы, и это нормально.

Переменная экземпляра с орфографической ошибкой не приводит к ужасной смерти программы, что плохо.Для выявления таких случаев используйте предупреждения .К сожалению, вы не можете легко сказать ruby ​​ рассматривать предупреждения как ошибки .

1 голос
/ 21 марта 2010

TDD - сначала напишите свои тесты, а затем самый простой код для прохождения теста.Таким образом, вы можете быть более уверены, что у вас нет непроверенного кода.Это поможет убедиться, что в вашем коде меньше опечаток или других ошибок.

Парное программирование / обзоры кода - две пары глаз лучше, чем одна.не панацея, но большая помощь в том, чтобы не делать опечаток.Если вы используете intellisense, вы обычно получаете ошибки подстановки, а не опечатки.Это не должно быть трудно найти с помощью тестов.

0 голосов
/ 09 января 2011

В Groovy абстрактное синтаксическое дерево (AST), составляющее программу, легко доступно. Таким образом, можно написать инструменты, которые проверяют AST и выдают предупреждения о том, что, вероятно, является ошибкой.

Например, GroovyLint предупредит вас, если вы попытаетесь вызвать метод, который не существует во время компиляции, но очень близок к тому, который существует.

Пример:

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

Test.fooBar() //Here GroovyLint suggests calling foobar instead of fooBar.
0 голосов
/ 21 марта 2010

Я пишу весь свой код Python в Eclipse IDE. Как предположил Младен Ябланович, затмение подчеркивает подозрительные части.

Следующий шаг - запустить код. Теперь есть два вида ошибок, с которыми я могу столкнуться.

  1. Ошибки, которые интерпретатор перехватывает и дает мне номер строки: Обычно их довольно легко отлаживать, особенно если вы печатаете все переменные в этой строке непосредственно перед этой строкой, чтобы убедиться, что они содержат значения что вы ожидаете.

  2. Неожиданное поведение: ваш код в порядке, и интерпретатор не жалуется, но ваш код ведет себя не так, как вы этого хотите. Когда это происходит (редко, потому что я обычно достаточно хорошо проектирую свои модули - процесс, который занимает около 7 минут - прежде чем я начну кодировать), я начинаю смотреть на модули / функции в порядке их вызова и пытаюсь выполнить программу в моя голова как переводчик увидит это. Если это не сработает, я продолжу исследовать отладчик. Обычно это не сводится к этому, но если это так, то это довольно большая ошибка, и на ее устранение потребуется довольно много времени. Модульные тесты помогают, но, честно говоря, я думаю, что как компьютерный специалист, я должен быть в состоянии отладить его с точки зрения анализа алгоритмов, который обычно быстрее, чем модульное тестирование (по крайней мере, для меня). Кроме того, выбор анализа алгоритмов по сравнению с модульным тестированием тренирует мой мозг, так что я не буду допускать таких ошибок в будущем, в отличие от модульного тестирования, которое помогает мне решить проблему сейчас, но мало помогает я избегаю повторения той же / подобной ошибки в будущем.

Надеюсь, это поможет

0 голосов
/ 21 марта 2010

Многие инструменты модульного тестирования могут отображать процент проверенных строк.Чем ближе этот процент к 100%, тем меньше вероятность опечатки имени переменной.

...