Отладка Ruby / Python / Groovy - PullRequest
Новая
       44

Отладка Ruby / Python / Groovy

1 голос
/ 30 июля 2009

Я перефразирую этот вопрос, потому что он был либо слишком неинтересен, либо слишком непонятен. :)

Первоначальный вопрос возник из-за того, что я делаю переход с Java на Groovy, но этот пример может в равной степени применяться при переходе на любой из языков более высокого уровня (Ruby, Python, Groovy).

Java легко отлаживать, поскольку существует четкая связь между строками кода и довольно тонким поведением, например, манипулировать массивом с помощью цикла for: 

for ( int i=0; i < array1.size(); i++ )
{
    if ( meetsSomeCriterion(array1.elementAt(i) )
    {
        array2.add( array1.elementAt(i) );
    }   
}

так что вы можете установить точку останова на тесте в цикле и посмотреть, что будет дальше. (Я знаю, что есть лучшие способы написать это; это просто для иллюстрации.)

В таких языках, как Ruby, кажется, что идиоматический стиль предпочитает высокоуровневое однострочное кодирование, например от http://rubyquiz.com/quiz113.html

quiz.to_s.reverse.scan(/(?:\d*\.)?\d{1,3}-?/).join(',').reverse

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

Спасибо!

Ответы [ 3 ]

3 голосов
/ 14 сентября 2009

Если бы я отлаживал ваш пример, первое, что я бы сделал, это разбил его на несколько этапов. Мне все равно, является ли это "pythonic" или "ruby way" или "tclish" или чем-то подобным, код, подобный этому, может быть сложным для отладки.

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

2 голосов
/ 14 сентября 2009

Объединение нескольких действий в одну строку - это хорошо, когда вы все еще можете посмотреть на соответствующую строку и знать, что она будет делать именно то, что вы хотите, чтобы она делала. В ту минуту, когда вы дошли до того, что вы не можете посмотреть на код и сказать «да, хорошо, он делает xyz, нет никакого способа, которым он не мог бы», когда вы должны рассмотреть возможность разбить его на отдельные части.

Я даю тот же совет людям с длинными проками / методами. Если вы не можете посмотреть на код и точно знать, что он делает во всех ситуациях, разбейте его. Вы можете разбить каждый из «неочевидных» фрагментов кода на его собственный метод и написать тесты только для этого фрагмента. Затем вы можете использовать этот метод в своем исходном методе и знать, что он будет работать ... плюс ваш оригинальный метод теперь легче понять.

В том же ключе вы можете разбить ваш код "scan (/ (?: \ D *.)? \ D {1,3} -? /)" На другой метод и протестировать его самостоятельно. Исходный код может затем использовать этот метод, и он должен быть намного легче понять и знать, что он работает.

0 голосов
/ 14 сентября 2009

Если мне придется отладить такую ​​строку, как та, которую вы опубликовали, я обнаружу, что ничто так не помогает, как разбивка ее на отдельные утверждения. Таким образом, вы можете увидеть, что каждый метод получает в качестве параметра, и что он возвращает.

Такие операторы затрудняют поддержку кода.

...