Debugging a scripting language such as ruby

Question

I am mainly from the world of C programming, now I delve into the world of scripting languages ​​such as Ruby and Python.

I am wondering how to do debugging. Currently, the following steps:

• I am completing a large script,
• Comment everything except part I want to check
• Execute script

Although it works, I cannot debug, as I would do, for example, in a VC ++ environment or something like that.

My question is, is there a better way to debug?

Note. I think this may be a repeated question, if so, please indicate me the answer.

Answer 1

Your sequence seems completely opposite to me. Here is how I do it:

• I am writing a test for the functionality I need.
• I start writing a script by executing a bit and checking the test results.
• I look through what I did to document and publish.

In particular, I perform before completing. It is too late.

There are debuggers, of course, but with good tests and a good design, I almost never needed it.

Answer 2

Here's a screencast for debugging ruby ​​with ruby-debug.

Answer 3

It seems that the problem is that your environment (Visual Studio) does not support these languages, and not that these languages ​​do not support debuggers in general.

Perl, Python, and Ruby have full-featured debuggers; You can also find other IDEs that will help you too. For Ruby, there is RubyMine ; for Perl, Komodo . And this is just from my head.

Answer 4

The Python debugger has a nice gentle view here

Answer 5

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

Answer 6

Languages

Scripts do not differ in comparison with other languages ​​in the sense that you still have to break your problems into manageable parts, that is, functions. So, instead of testing the entire script after the completion of the entire script, I prefer to test these small functions before integrating them. TDD always helps.

Answer 7

My question is, is there a better way to debug? "

Yes.

Your approach is "1. I am completing a large script, 2. Commenting on everything except the part I want to test, 3. Run the script", is actually not the best way to write any software in any language (sorry, but it's true .)

Do not write anything big. Someday.

Do it.

• Break your problem down into object classes.

• For each class write a class

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

  2b. Write tests to prove that the interface works.

  2c. Run the tests. They will fail because you just outlined the class.

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

  2e. In some cases, you will realize that the design of your class is not optimal. Refactor your design, ensuring your tests still pass.

• Now write the final script. It should be short. All classes are already tested.

  3a. Draw a script. In fact, you can usually write a script.

  3b. Write some test cases confirming the script.

  3c. Run tests. They can pass. All is ready.

  3d. If the tests fail, correct everything until they do.

Write a lot of little things. Ultimately, in the end it turns out much better that writing a big thing and commenting on its parts.

Answer 8

Here are a lot of good tips, I recommend reviewing some of the 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, that's excellent)

---

You are talking about big scenarios. Most of my workflow develops logic in irb or the python shell, and then captures them in a cascade of small, single-task focused methods, with appropriate tests (not 100% coverage, more attention on edge and corner cases).

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

Answer 9

There is a question about the Ruby IDE here - and a search for the “Ruby IDE” offers more.

I am completing a large script

What caught my attention: "complete", for me, means "done", "finished", "released." Regardless of whether you write tests before writing functions that are passed to them or don’t write tests at all (and I recommend that you do this), you should not write code that cannot be run (which in itself) until it becomes large . Ruby and Python offer many ways to write small, individually verifiable (or executable) snippets of code, so you don’t have to wait (?) Days before you can run this thing.

I am building a translation / conversion (Ruby) database (Ruby) script at the moment - it is up to about 1000 lines and has not yet been completed. I rarely go over 5 minutes without starting it, or at least work on the part that I work on. When it breaks (I'm not perfect, it breaks badly; -p) I know where the problem should be - in the code that I wrote in the last 5 minutes. Progress is pretty fast.

I am not saying that IDEs / debuggers have no place: some problems do not arise until they release a large piece of code: sometimes it is useful to immerse all this in the debugging environment to find out what is happening. When third-party libraries and frameworks are involved, it can be extremely useful to debug their code to find problems (which are usually - but not always - associated with a misunderstanding of the library function).

Answer 10

You can debug your Python scripts using the included pdb module. If you want a visual debugger, you can download winpdb - do not put off this "win" prefix, winpdb is cross -platform.

Answer 11

The debugging method that you described is ideal for a static language such as C ++, but provided that the language is so different, the encoding methods are similar to each other. One of the important very important things in a dynamic language, such as Python or Ruby, is interactive toplevel (what you get by typing, say, python on the command line). This means that executing part of your program is very simple.

Even if you wrote a great program before testing (this is a bad idea), we hope to divide it into many functions. So, open your interactive level, do an import thing (for any thing ), and then you can easily start testing your functions one by one by simply calling them at the top level.

Of course, for a more mature project, you probably want to write down the actual test suite, and most languages ​​have a way to do this (in Python these are doctest and nose , I don't know about other languages). At first, however, when you write something not quite formal, just remember a few simple rules for debugging dynamic languages:

• Start small. Do not write large programs or test them. Check every function when you write it, at least easily.
• Use the top level. Running small pieces of code in a language such as Python is extremely easy: launch the top layer and run it. Compare with writing a complete program and compiling it, say, in C ++. Use the fact that you can quickly change the correctness of any function.
• Debuggers are convenient. But often these are also print expressions. If you use only one function, debugging with print statements is not inconvenient, and also frees you from dragging and dropping around the IDE.