Debugging a scripting language like ruby

Question

I am basically from the world of C language programming, now delving into the world of scripting languages like Ruby and Python.

I am wondering how to do debugging. At present the steps I follow is,

• I complete a large script,
• Comment everything but the portion I want to check
• Execute the script

Though it works, I am not able to debug like how I would do in, say, a VC++ environment or something like that.

My question is, is there any better way of debugging?

Note: I guess it may be a repeated question, if so, please point me to the answer.

Worldlywise

If you think it might be a repeat question, why not search for it on Stack Overflow before asking it? – Prosody

@Chris Lutz, I searched before asking this question and could not find any hit. But, I was sure that this is such a generic topic that there should be some questions asked earlier... – Worldlywise

Answer 1

Your sequence seems entirely backwards to me. Here's how I do it:

1. I write a test for the functionality I want.
2. I start writing the script, executing bits and verifying test results.
3. I review what I'd done to document and publish.

Specifically, I execute before I complete. It's way too late by then.

There are debuggers, of course, but with good tests and good design, I've almost never needed one.

Cracker

Not everybody is quite this gung-ho about it (writing tests before actual code), but unit tests are hugely important for this sort of thing in Ruby. – Floristic

Debugging is essential for finding wired bugs, but to verify that your code actually does what you want during development process unit tests are much better and you get the possibility to rerun them. – Permatron

TDD is essential for preventing bugs, removing any need for complex debugging practices. – Judi

Debuggers definitely have their uses – Scornful

@Judi exactly, but debuggers still make sense when code written by others fails. When TDD let some bugs pass, you still might need a debugger to fix them. – Bul

Answer 2

Here's a screencast on ruby debugging with ruby-debug.

Nibelungenlied

Answer 3

Seems like the problem here is that your environment (Visual Studio) doesn't support these languages, not that these languages don't support debuggers in general.

Perl, Python, and Ruby all have fully-featured debuggers; you can find other IDEs that help you, too. For Ruby, there's RubyMine; for Perl, there's Komodo. And that's just off the top of my head.

Chromoplast

Answer 4

There is a nice gentle introduction to the Python debugger here

Purser

Answer 5

If you're working with Python then you can find a list of debugging tools here to which I just want to add Eclipse with the Pydev extension, which makes working with breakpoints etc. also very simple.

Infer

Answer 6

Script languages have no differences compared with other languages in the sense that you still have to break your problems into manageable pieces -- that is, functions. So, instead of testing the whole script after finishing the whole script, I prefer to test those small functions before integrating them. TDD always helps.

Illiberal

Answer 7

My question is, is there any better way of debugging?"

Yes.

Your approach, "1. I complete a large script, 2. Comment everything but the portion I want to check, 3. Execute the script" is not really the best way to write any software in any language (sorry, but that's the truth.)

Do not write a large anything. Ever.

Do this.

1. Decompose your problem into classes of objects.

2. For each class, write the class by

   2a. Outline the class, focus on the external interface, not the implementation details.

   2b. Write tests to prove that interface works.

   2c. Run the tests. They'll fail, since you only outlined the class.

   2d. Fix the class until it passes the test.

   2e. At some points, you'll realize your class designs aren't optimal. Refactor your design, assuring your tests still pass.

3. Now, write your final script. It should be short. All the classes have already been tested.

   3a. Outline the script. Indeed, you can usually write the script.

   3b. Write some test cases that prove the script works.

   3c. Runt the tests. They may pass. You're done.

   3d. If the tests don't pass, fix things until they do.

Write many small things. It works out much better in the long run that writing a large thing and commenting parts of it out.

Judi

TDD is a methodology, not a debugging tool like the OP is asking about. – Leonor

@Josh Smeaton: Debugging is a technique; so is TDD. I prefer the TDD technique over the write and debug technique. It works out better for me. – Judi

S. Lott, debugging is not a 'technique' -- and even if it was a 'technique' (ugh) it is not completely replaceable by TDD. – Titus

@banister: If debugging is not a technique, what is it? It certainly seems like a thing people do that requires skills. It's not a methodology. And, debugging changes dramatically with TDD to an exercise of writing more and more tests to ferret out a problem. Sounds like a technique to me. – Judi

Debugging is a task, not a technique. Just as writing code is a task debugging code is an other task of fixing things. TDD is how to write code in a way to not have to debug it. Yet, TDD doesn't solves problem created by the code you didn't write. Let say you use a add function that adds correctly every number except 12324 + 54532 would give 12 because one idiot made that unlikely special case somewhere... That's when a debugger makes a lot of sense... – Bul

Answer 8

The debugging method you described is perfect for a static language like C++, but given that the language is so different, the coding methods are similarly different. One of the big very important things in a dynamic language such as Python or Ruby is the interactive toplevel (what you get by typing, say python on the command line). This means that running a part of your program is very easy.

Even if you've written a large program before testing (which is a bad idea), it is hopefully separated into many functions. So, open up your interactive toplevel, do an import thing (for whatever thing happens to be) and then you can easily start testing your functions one by one, just calling them on the toplevel.

Of course, for a more mature project, you probably want to write out an actual test suite, and most languages have a method to do that (in Python, this is doctest and nose, don't know about other languages). At first, though, when you're writing something not particularly formal, just remember a few simple rules of debugging dynamic languages:

• Start small. Don't write large programs and test them. Test each function as you write it, at least cursorily.
• Use the toplevel. Running small pieces of code in a language like Python is extremely lightweight: fire up the toplevel and run it. Compare with writing a complete program and the compile-running it in, say, C++. Use that fact that you can quickly change the correctness of any function.
• Debuggers are handy. But often, so are print statements. If you're only running a single function, debugging with print statements isn't that inconvenient, and also frees you from dragging along an IDE.

Forthright

Answer 9

There's a SO question on Ruby IDEs here - and searching for "ruby IDE" offers more.

I complete a large script

That's what caught my eye: "complete", to me, means "done", "finished", "released". Whether or not you write tests before writing the functions that pass them, or whether or not you write tests at all (and I recommend that you do) you should not be writing code that can't be run (which is a test in itself) until it's become large. Ruby and Python offer a multitude of ways to write small, individually-testable (or executable) pieces of code, so that you don't have to wait for (?) days before you can run the thing.

I'm building a (Ruby) database translation/transformation script at the moment - it's up to about 1000 lines and still not done. I seldom go more than 5 minutes without running it, or at least running the part on which I'm working. When it breaks (I'm not perfect, it breaks a lot ;-p) I know where the problem must be - in the code I wrote in the last 5 minutes. Progress is pretty fast.

I'm not asserting that IDEs/debuggers have no place: some problems don't surface until a large body of code is released: it can be really useful on occasion to drop the whole thing into a debugging environment to find out what is going on. When third-party libraries and frameworks are involved it can be extremely useful to debug into their code to locate problems (which are usually - but not always - related to faulty understanding of the library function).

Ataraxia

Answer 10

You can debug your Python scripts using the included pdb module. If you want a visual debugger, you can download winpdb - don't be put off by that "win" prefix, winpdb is cross-platform.

Selfabnegation

Answer 11

There's a lot of good advice here, i recommend going through some best practices:

http://github.com/edgecase/ruby_koans

http://blog.rubybestpractices.com/

http://on-ruby.blogspot.com/2009/01/ruby-best-practices-mini-interview-2.html

(and read Greg Brown's book, it's superb)

---

You talk about large scripts. A lot of my workflow is working out logic in irb or the python shell, then capturing them into a cascade of small, single-task focused methods, with appropriate tests (not 100% coverage, more focus on edge and corner cases).

http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html

Fireboard