Захват опечаток на языках сценариев

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

Пара/программирование кода - две пары глаз лучше одной пары.

IDE с intellisense - не панацея, но большая помощь в том, чтобы не делать опечатки. Если вы используете intellisense, вы обычно получаете ошибки замещения, а не опечатки. Их не сложно найти с помощью тестов.

Ответ 5

В рубине локальная переменная с ошибкой заставит программу умереть ужасно, что хорошо.

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

Ответ 6

В моем случае я интенсивно использую модульное тестирование (разработка на 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.

Ответ 7

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

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

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

Я также использую Test Driven Development с целью покрытия 100% unit test.

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

Ответ 8

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

Ответ 9

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

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

Пример:

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

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

Ответ 10

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

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

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

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

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