iOS Debugging - When you were new to programming

[PriapusZA]

Hi guys,

So this year I have stepped up my programming a lot (Now employed as a Jnr Dev ) so I get to do this all day every day

My biggest problem right now though is finding syntax errors that don't give compile time errors.

For example I was just busy with a card game and the game wasn't behaving as expected.
An hour later I found that it was due to not including a "not" operator in one of my lazy instantiations. Very annoying..

Because the game was't flipping the cards I assumed it was due to an error in the view and not the model. But it was in the model.

So what I want to find out - when you first started programming - did you spend longer than needed looking for syntax errors and as time went on - did you become better at it?

Appreciate all feedback.

 

[robbieduncan]

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

 

[PriapusZA]

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

Ah that's a better word for it.

The point is, I knew I had to put it in my instantiation - but when I had gotten to the end of the programming and onto testing - I missed that operator.

I think as I am reading my code - maybe I should try read it out as instructions rather than just looking at the different syntax's etc?

Sorry if this all seems completely basic - I am following Stanford's online courses and still new to this.

 

[robbieduncan]

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

 

[PriapusZA]

I have probably around 3 solid weeks of experience. So I am hoping to get better as I go along!

Thanks for your feedback.

 

[xArtx]

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!

 

[PhoneyDeveloper]

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.

 

[balamw]

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

And everyone can stare at a section of code for hours not seeing the obvious problem in front of them.

I ran into an assignment vs. comparison in some code I was debugging (from outside the company) which was working as we wanted, but we could not understand why. Turns out the original developer had an

if (length = EXPECTED_LENGTH)

in his code (which is always true) instead of

if (length == EXPECTED_LENGTH)

Of course if he had done it this way:

if (EXPECTED_LENGTH == length)

the compiler would have caught it.

B

 

[robbieduncan]

the compiler would have caught it.

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.

 

[Duncan C]

Hi guys,

So this year I have stepped up my programming a lot (Now employed as a Jnr Dev ) so I get to do this all day every day

My biggest problem right now though is finding syntax errors that don't give compile time errors.

For example I was just busy with a card game and the game wasn't behaving as expected.
An hour later I found that it was due to not including a "not" operator in one of my lazy instantiations. Very annoying..

Because the game was't flipping the cards I assumed it was due to an error in the view and not the model. But it was in the model.

So what I want to find out - when you first started programming - did you spend longer than needed looking for syntax errors and as time went on - did you become better at it?

Appreciate all feedback.

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.

 

[PriapusZA]

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.

Thank you Duncan - that helps a lot.

My main issue is I have no one I know in real life who is a mobile developer and most of you guys are in different time zones to me.
So asking online means waiting days sometimes.

Is there a "real time" chat available with other developers?

Sometimes its easier to ask someone for quick explanations.

 

[Duncan C]

Thank you Duncan - that helps a lot.

My main issue is I have no one I know in real life who is a mobile developer and most of you guys are in different time zones to me.
So asking online means waiting days sometimes.

Is there a "real time" chat available with other developers?

Sometimes its easier to ask someone for quick explanations.

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.

 

[PriapusZA]

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.

I'm in South Africa. Our local mobile development is not great at all.

Again, I appreciate all your help.

 

[balamw]

I'm in South Africa. Our local mobile development is not great at all.

Not non-existant either. https://groups.google.com/forum/?fromgroups#!forum/cocoaheads-jnb

B

 

[mslide]

So what I want to find out - when you first started programming - did you spend longer than needed looking for syntax errors and as time went on - did you become better at it?

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.

in his code (which is always true) instead of

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.

 

[balamw]

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 believe it is already the default in Xcode. Unfortunately this was PIC code and I am not aware of such a setting for Microchip's compiler.

B

 

[Duncan C]

I'm in South Africa. Our local mobile development is not great at all.

Again, I appreciate all your help.

Are you in or near a major city?

----------

And everyone can stare at a section of code for hours not seeing the obvious problem in front of them.

I ran into an assignment vs. comparison in some code I was debugging (from outside the company) which was working as we wanted, but we could not understand why. Turns out the original developer had an

in his code (which is always true) instead of



Of course if he had done it this way:



the compiler would have caught it.

B

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.)

 

[ArtOfWarfare]

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.

 

[firewood]

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.

 

[xArtx]

I believe it is already the default in Xcode. Unfortunately this was PIC code and I am not aware of such a setting for Microchip's compiler.

B

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

 

[dejo]

Rinse and repeat as necessary.

A college professor of mine spoke at our graduation banquet. One of the things I remember most keenly is that he said: "Only a programmer would read the directions on a shampoo bottle ('rinse and repeat.') and realize there's an infinite loop there."

 

[balamw]

One of the keys to debugging is to learn to divide and conquer.

IMO this is the main draw for me to both OOP and MVC. Clearly delineating what each part of the code does what makes debugging and maintenance much easier.

Not that you can't do it in a procedural language, but it just takes more effort.

Another habit I've gotten into is to try to make sure each section of code I am working on can be seen on a single screen (until optimization for performance or other makes it impossible.)

B

 

[Duncan C]

A college professor of mine spoke at our graduation banquet. One of the things I remember most keenly is that he said: "Only a programmer would read the directions on a shampoo bottle ('rinse and repeat.') and realize there's an infinite loop there."

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.)

 

[ArtOfWarfare]

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.

 

[Duncan C]

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.