Pages: [1] 2 3   Go Down
Author Topic: teaching debugging  (Read 2425 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
God Member
*****
Karma: 32
Posts: 830
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Sometimes when I read a request for help on here, and other forums, I'm often struck by the apparent lack of debugging skills of the applicant, implicit in the wording of their plea. Things like "I'm out of ideas as to what might be wrong" or similar.

There are a lot of resources out there on how to code available on the 'net and in bookstores, but far fewer on how to systematically debug that code.

I don't see any reason why debugging skills can't be taught, yet it seems they rarely are. The basic principles are not difficult, at least I wouldn't have thought so, yet my observation is that they don't necessarily come automatically to people, sometimes even to those who are quite bright and otherwise show considerable aptitude for programming.

The saying about "give a man a fish..." comes to mind. Perhaps we could put together some "how to fish" resources tailored for Arduino users? (I know Nick Gammon was preparing some "Introduction to Arduno programming" guides a while back, and I did suggest something along these lines to him back then, but not sure if anything came of it.)

Thoughts?
Logged

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

New Jersey
Offline Offline
Faraday Member
**
Karma: 67
Posts: 3674
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It might help to introduce the topic in a non-coding context; start with some situations from daily life where you would use debugging skills. One example I've used here before is - what do you do when a light doesn't come on in your house?

Or what do you do when your car won't start?

Once you show you audience that they actually know perfectly well what the debugging process is, you can introduce the tools (such as they are) that would be used in an arduino context.

Then perhaps, do a couple of worked examples showing the process that was used to debug a real piece of code. I recall finding a piece on C++ design really useful where, rather than showing some classes that appeared out of the air, the author showed all his attempts and backtracks that produced the final pristine design. "What I did to debug this, warts and all" might be more useful than a beautiful analytic track straight to the solution.

I wouldn't be inclined to spend much time on such a thing though - there are many posters that make it clear that they didn't read Nick's existing sticky so adding more stuff that will be ignored isn't a very appealing prospect.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 132
Posts: 6739
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

In my experience, it's difficult to teach/learn "testing", much less "debugging."
Since debugging is essential "test in a way that enables you to figure out WHAT is wrong", this is a problem :-(
(although people who are good at debugging are not necessarily good at testing.  Sigh.)
Logged

WIsconsin
Offline Offline
Full Member
***
Karma: 3
Posts: 159
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The concept of debugging can be taught, but the act of debugging is pretty much going to be a learned skill. People can't really debug their code unless they understand it completely. Then they can find problems with the code by using their knowledge of how it should be working.

I programmed for Microsoft for 15 years or so, and after a while, I got to the point where I could see an error or something happen unexpected in the program and instantly know what was wrong with the code before even looking back at the code. It's just something that is learned over time.

It can be taught, but there is a time when people just need to have experience.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 132
Posts: 6739
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

And you have to look.  And try.  Or you get bugs like apple's recent embarassment:
Logged

WIsconsin
Offline Offline
Full Member
***
Karma: 3
Posts: 159
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

LOFL   smiley-yell

And you have to look.  And try.  Or you get bugs like apple's recent embarassment:

Logged

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 126
Posts: 8490
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yeah that Apple bug is a classic smiley

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

Offline Offline
God Member
*****
Karma: 32
Posts: 830
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Since debugging is essential "test in a way that enables you to figure out WHAT is wrong", this is a problem :-(

Interesting to bring up the relationship between testing and debugging, although they are quite different things.

The purpose of a test is to evaluate the current condition of something, whereas debugging is a process to understand and fix something that isn't working as expected.

Having said that, systematic debugging typically involves a series of tests, where the outcome of each tests guides the next step in the process.

But this leads to another distinction: Systematic debugging vs non-systematic debugging.

Both systematic and non-systematic debugging can be successful. Indeed, CSGuy's "inspiration" debugging is an example of non-systematic debugging. It's entirely reliant on an "aha!" insight, and as such, there is no process or structure, and so there is nothing that can be taught there.

Many posters who appeal for help with their programs I suspect are also non-systematic debuggers, as they will often say things like "I am completely out of ideas -- please help guys", suggesting that an idea or inspiration as to what the problem might be is necessary to continue.

Sound systematic debugging methods, OTOH, do not rely on "new ideas" or "insight" proceed, as they generally progress by elimination through test and verification (or not) of the debugger's assumptions. The systematic approaches when formalised resemble algorithms. If applied diligently, they will (almost) always succeed, although perhaps converge slowly as a process. Less inspiration and more perspiration, as Edison might have said.

So to clarify, my suggestion is that *systematic* forms of debugging might be something useful to try to teach. Further, I suspect trying to teach any of the various non-systematic approaches wouldn't be very useful, as a) they are probably self-evident anyway, and b) they are usually what have already been exhausted by the time a poster asks for help. (Although I have my suspicions that some posters haven't applied *any* debugging method -- they wrote the code, compiled it, and found it didn't work as expected, and then were at a complete loss as to how to proceed.)

In conjunction with the "process" side of systematic debugging, specific tips and techniques particularly suitable for the Arduino environment could be discussed. Also, the more esoteric aspects of the subject like dealing with so-called "Heisenbugs" might be worth some discussion.

Anyway, just putting it out there (hence Bar Sport!)

« Last Edit: March 09, 2014, 10:44:38 am by pico » Logged

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

Offline Offline
God Member
*****
Karma: 32
Posts: 830
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I wouldn't be inclined to spend much time on such a thing though - there are many posters that make it clear that they didn't read Nick's existing sticky so adding more stuff that will be ignored isn't a very appealing prospect.

Fair comment too. :-(
Logged

WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

Pittsburgh, PA, USA
Offline Offline
Faraday Member
**
Karma: 98
Posts: 4801
I learn a bit every time I visit the forum.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

You have to be able to read the code line by line and be able to follow how it (should) executes.
You need to know about conditional branches and loops, variables, arrays, structs and pointers and C++ Classes at some point going from just started to confident and able to add print statements.

And how to get there?

There's the foundations page for raw beginners to learn some terms and concepts:
http://arduino.cc/en/Tutorial/Foundations#.Uxu4Gkgz3jI

and then they go through the examples (in the the IDE) but not in 1-2-3 order.
More like section 5 first then 1 then 2 then 3.. and then find a good tutorial on C string arrays/string.h

Arduino string.h library source is in your IDE source code.. A function reference is here:
http://www.nongnu.org/avr-libc/user-manual/group__avr__string.html

that you get to from the main library page:
http://www.nongnu.org/avr-libc/user-manual/modules.html

If you got this far then you have probably done some debugging already.
Logged

I find it harder to express logic in English than in Code.
Sometimes an example says more than many times as many words.

Offline Offline
Sr. Member
****
Karma: 3
Posts: 251
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thoughts?

How about instead of
" publish your full code... put your code in quotation... read blink without delay ...format your code...

FAQ forum


Here is a start

1. if(a=1)
       digitalWrite (pin1 ,a);
       Assigment (=) versus evaluation (==)

2. if(a != 1 );
        digitalWrite(pin1,HIGH);
        
      if(condition) statement;
      Missing statement

3. XYZ myClass;

     compiler error  XYZ does not name type

    The compiler does not recognize variable type XYZ  ( int, char etc. ) Most likely missing library.


4. if(a ==1)
          digitalWrite(pin1,a);
    else if( a == 0)
          digitalWrite(pin1,a);
     
     if it is not true , it must be false - it is digital

     if(a)                                            // if true 
          digitalWrite(pin1,HIGH);      // LED ON 
      else
          digitalWrite(pin1,LOW);      // LED OFF   





      
« Last Edit: March 12, 2014, 05:28:07 pm by Vaclav » Logged

Pittsburgh, PA, USA
Offline Offline
Faraday Member
**
Karma: 98
Posts: 4801
I learn a bit every time I visit the forum.
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Sometimes you can get a little preemptive debug training in by telling someone to break that big (usually first) project down into pieces and add a piece at a time because it's generally easier to debug that way.
Logged

I find it harder to express logic in English than in Code.
Sometimes an example says more than many times as many words.

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

4. if(a ==1)
          digitalWrite(pin1,a);
    else if( a == 0)
          digitalWrite(pin1,a);
     
     if it is not true , it must be false - it is digital

Well, not always..

Code:
if (a == 1)
    digitalWrite(pin1, a);
else if (a == 0)
    digitalWrite(pin1, a);
else
    Serial.println("Uh oh!  Invalid state. (a = %u)", a);

Now, usually, your perspective is correct and what the OP intended with the conditional statement.  However, this it the kind of ambiguity I like to point out, because the code isn't actually invalid and might not be an error at all.  The OP would need to either clarify that a boolean condition isn't adequate, and maybe why (if it's not obvious), or they should've just written this:

Code:
digitalWrite(pin1, a);  // Why test the value at all?

I like to show people when they're doing something that gives the correct result, but for the wrong reasons (or just bad form.)  I find I've learned a lot by similar lessons and like to pass that on.  So far, I've gotten a lot of "OH, I didn't know that!" replies, so hopefully it's helping.
Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

And you have to look.  And try.  Or you get bugs like apple's recent embarassment:


Things like this are good exercises for newbies.  (And the rest of us for that matter.)  When presented in a forum like this, it becomes a kind of game to figure out the bug.  For example, at least taken out of context, I see a few potential flaws in this...

1) Several variables aren't defined.  Now, they're probably defined in the "..." but then again maybe they're not.  After all, we see one variable defined, then a snip, then code.  Attention to detail would reveal that hashCtx, serverRandom, hashOut, and signedHashes weren't parameters and weren't defined.  Are they global?  Obviously the code wouldn't even compile if they weren't defined at all, making it unlikely this bug would make it into the wild, unless distributed as source rather than a compiled executable.  But a good developer should be asking him/herself these questions regardless.

2) What's UInt16?  (I could be showing my ignorance here.)  How's that different from the actual C99 type uint16_t?  Was that a typo?  (Again, it would fail to compile if it were actually mistake.)

3) While not necessarily indicative of a problem, every developer should be suspicious of those pointers, custom types lacking pointers, and address-of operators.  It's such a common source of errors that it should be reflex to examine them, even if compiler warnings are turned on and "should" complain if they don't match up.

4) Obviously (and the point of this snippet, I'm sure) is the fact that there are two "goto fail;" statements after a conditional.  The second is indented like it's supposed to be executed after the second conditional fails, but without block braces, the compiler will treat it as a statement that will be executed as a matter of course after passing the first two conditionals.
Logged

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 126
Posts: 8490
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

That's the Apple bug eh? A classic example of "reading the indentation" and a big goto fail for the coder smiley

Interesting that they use uint8_t but then UInt16. Maybe it makes sense in context.

______
Rob
« Last Edit: March 13, 2014, 04:49:59 pm by Graynomad » Logged

Rob Gray aka the GRAYnomad www.robgray.com

Pages: [1] 2 3   Go Up
Jump to: