Debugging - When you were new to programming

That's not a syntax error. That's a logic error in your programming.

 

I'd say this sort of thing gets less frequent with experience but everyone makes mistakes!

 

I think you get better at knowing what you're looking for,

but still the error seems to be always something a lot simpler than you thought!

 

Obviously with more experience you make fewer logic errors and you know what to look for to find logic errors.

Some good practices are to always read your code after you make a change and before you run the code. Always step through new code in the debugger and check that it's doing the right thing. Use NSAssert a lot to check your expectations in all your methods.

Imagine that instead of taking thirty seconds to compile, run, debug it takes an hour, or twenty-four hours. You would double check the code very carefully if it took a long time to compile and run.

 

A "trick" I tend to exploit. Another good tip in C-like languages is to use the // style comments for normal comments allowing you to freely use the /* */ style when you need to comment out sections without worrying about a pre-existing close comment */ having unintended consequences.

 

Absolutely, it gets easier. However, I am still not great at syntax. I have a hellova time balancing curly braces, or reading long nested method calls with 5 levels of square brackets. Nested block calls are the worst.

I've been doing this long enough that design errors are pretty rare with me. I design a solution, implement it, then test it and figure out where I made typos, copy/paste errors, etc. Like most of us, I sometimes spend hours trying to figure out why a program won't work, only to find that I made some stupid editing error.

It pays to learn to use the debugger. Learn how to single-step. Learn how to look at the variables view and see the values of your variables change. Learn how to create conditional breakpoints, and how to attach log statements and other debugger commands to breakpoints.

Then, when a block of code isn't behaving as you expect it to, you step through and watch what happens. That usually points you at the problem fairly quickly.

 

Dunno about live chat.

Where are you located? I would suggest joining a local developer's group. NSCoder and CocoaHeads are both Apple developer organizations with branches all over the US. Not sure about other countries.

 

It gets easier with experience but everybody makes mistakes and winds up spending too much time looking for a silly mistake now and then. My biggest advice is to A) learn to use a debugger and B) turn on all compiler warnings and always fix them (treat them like errors). Learning to use a debugger is really important. It's much better than just staring at your code, hoping your mistake will jump out at you, or using print/log statements. I'm shocked at how many 'experienced' programmers I run into who still debug their code by placing print statements all over the place. I wish schools placed a larger emphasis on debugging code.

Lastly, write unit tests for your code even for sections that seem trivial to you. It might feel like it's more trouble than it's worth when starting out but it'll pay off in the long run.

I know nothing about iOS development but these are general programming tips that apply to all areas, no matter how high or low level it is.

Again, I'm not familiar with iOS programming but there should be a compiler option to flag this type of mistake as a warning (if it's not already by default). I feel like it's much more natural to write conditionals with the variable first and the constant/literal second. Then, I always set the warning level to the highest level and make sure I fix them all. That takes care of that kind of mistake for me without using the more awkward, reversed style.

 

Are you in or near a major city?

----------

Actually the LLVM compiler flags if (a=b) code with a warning.

One thing to remember is to use the analyze tool regularly. It catches logic problems in your code that normal compilation does not. (Analyze under the project menu.)

 

Use unit tests.

This took a long time for me to learn because I couldn't understand the value.

The value is if you use them properly, you'll get error messages telling you exactly which method isn't behaving as it should, so you won't waste time looking in the wrong spots.

 

Quote from M.Wilkes, Turing award winning inventor of one of the very first working digital computers:

"As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

One of the keys to debugging is to learn to divide and conquer. Find someplace halfway to working correctly. Inspect. If it is or is not doing what you expected, then you know whether the bug is in the first or second half.

... unless there is more than one bug. ... or there is a mistake in what you expect. ... both of which happen more often than you expect. ... etc.

Rinse and repeat as necessary.

 

I wasn't going to bring it up here, but now that you went onto Microchip,
I totally fixed someone else's program last night by changing a zero to a one!

He was reading a voltage with an analogue pin and complained that his program
would work fine for three minutes, and then somehow the analogue pin changed
it's own state to a digital output (the micro pin side read zero), but the rest of
his program kept functioning which was controlling the PWM for a power supply!

He was telling his compiler to read a ten bit analogue value which sets
ADCON1 bit 7 to 1, and then manually setting it to 0 in asm for an 8 bit format.
What I think was happening was his compiler looking for a ten bit result in
an 8 bit register which is right next to ADCON1.
Looks like if his recieved analogue value was over 255, the port was switched
back to digital

 

Did you hear the one about the programmer found dead in the shower? He was, naturally, found clutching a shampoo bottle that read "Lather, rinse, repeat."



However, there's a problem with that joke.

There is an end condition. (You'd run out of shampoo eventually.)

 

I believe Stack Overflow has a live chat - I'm just skimming over this and saw someone wanted to know where they could find some live programming chat.

Also - someone mentioned reading a lot of nested brackets. Nested brackets are a bad code smell - the logic should be reworked, likely so that some of it is in entirely seperate functions or methods.

 

Agreed. I tend to write my code using a lot of simple statements and temporary variables. That has a couple of advantages: It makes the code easier to read, and it also makes it easier to debug, since I can easily add breakpoints and examine intermediate values.

Big complex statements make debugging much harder.

The compiler optimizes away temporary variables in the release build anyway, so there's no reason to write a single line that's half a page of code.