Project, how to debug

[Chris Angelico]

On Tue, Mar 31, 2015 at 10:23 PM, Robert Clove <cloverobert at gmail.com> wrote:
>
> I am facing a problem.
> I have been given a project written in python and asked to debug it.
> I have not been given the flow they said understand and debug.
>
> Can someone suggest me how to debug it in Wings IDE.
> Project have approx 10 files.

Hi, sounds like this is a homework assignment.

I don't know the IDE, so I'll just give some basic debugging advice.
Most of this isn't even specific to Python - it's simply how you go
about figuring out where a problem is in a piece of code.

The first step is *always* to find out what the code ought to be
doing. Should it be firing up a server of some sort? Running,
performing some task, and terminating? Producing output on the console
(stdout/stderr)? Bringing up a graphical window? If you don't already
know, you might be able to find out from hints in the code itself -
comments at the top, function names, string literals, that kind of
thing. Otherwise, ask someone. You can't assess whether the code's
doing the right thing or not without knowing what "the right thing"
means.

(Parenthesis: Some people think that a program crash is "the wrong
thing" and the program not crashing is "the right thing". This is
often enough true that it's very tempting, but if you believe your job
is to stop the program crashing, then all you have to do is remove
code until the failing part is gone. The result might not achieve
anything, but hey! It's not crashing, right? You need to start by
knowing what actual goal to not-remove. Also, sometimes it's
absolutely right for a program to throw an exception; a test script
for PEP 479 is simply probing to see which of two exceptions it gets,
and "success" is defined by getting a RuntimeError. End of
parenthesis.)

Once you know what the code ought to do, check to see whether you
trust the code enough to run it. In your case, you can probably trust
the code-provider to not have anything openly malicious in the code,
but otherwise, you'll need to look through the code, or run it in some
specialized environment like a virtual machine, or something like
that, to protect yourself. Remember, you're running code that someone
else gave you, and it's buggy. If the program's purpose is "delete
unnecessary files from your hard disk", then you want to be VERY
careful with it - one small bug, and it might wipe out a whole lot of
actively-used files. Just ask any sysadmin about the time he typed "rm
* .pyc" or equivalent.

So, you know what the program should do, and you either trust the
code, or have taken measures to protect yourself. Great! Now comes the
simple part: Run the program, see if it's doing what it should, and if
not, change something. Repeat until success.

'Course, I never said it was easy. Just simple. :)

Chances are you don't have enough information to know WHY it isn't
doing what it should, though, and that's where most of what people
talk of "debugging techniques" comes in. Your IDE might let you
single-step through the code, place breakpoints, and all sorts of
other fancy things; if so, use as many of those features as you're
comfortable with, and ignore the rest. Your basic debugging technique
will usually come down to one thing: Find out what the program's doing
at <some specific point>. And the simplest and most basic form of that
is what I call IIDPIO debugging: If In Doubt, Print It Out. Just add
print() calls to key parts of the code, reporting on the contents of
variables, or just announcing that control flow reached a certain
point. It's amazing how easy a debugging job can become when you just
get a little more info out of it.

Give that a try, and see how you go. If symptoms persist, see your teacher.

ChrisA