Debugging - When you were new to programming

Discussion in 'iOS Programming' started by Tander, Jun 7, 2013.

  1. Tander macrumors 6502a

    Tander

    Joined:
    Oct 21, 2011
    Location:
    Johannesburg, South Africa
    #1
    Hi guys,

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

    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. :cool:
     
  2. robbieduncan Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #2
    That's not a syntax error. That's a logic error in your programming.
     
  3. Tander thread starter macrumors 6502a

    Tander

    Joined:
    Oct 21, 2011
    Location:
    Johannesburg, South Africa
    #3
    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.
     
  4. robbieduncan Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #4
    I'd say this sort of thing gets less frequent with experience but everyone makes mistakes!
     
  5. Tander thread starter macrumors 6502a

    Tander

    Joined:
    Oct 21, 2011
    Location:
    Johannesburg, South Africa
    #5
    I have probably around 3 solid weeks of experience. So I am hoping to get better as I go along!

    Thanks for your feedback.
     
  6. xArtx macrumors 6502a

    Joined:
    Mar 30, 2012
    #6
    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!
     
  7. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #7
    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.
     
  8. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #8
    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
     
  9. robbieduncan Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #9
    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.
     
  10. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #10

    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.
     
  11. Tander thread starter macrumors 6502a

    Tander

    Joined:
    Oct 21, 2011
    Location:
    Johannesburg, South Africa
    #11
    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.
     
  12. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #12
    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.
     
  13. Tander thread starter macrumors 6502a

    Tander

    Joined:
    Oct 21, 2011
    Location:
    Johannesburg, South Africa
    #13
    I'm in South Africa. Our local mobile development is not great at all. :(

    Again, I appreciate all your help.
     
  14. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #14
  15. mslide macrumors 6502a

    Joined:
    Sep 17, 2007
    #15
    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.
     
  16. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #16
    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
     
  17. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #17

    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.)
     
  18. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #18
    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.
     
  19. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #19
    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.
     
  20. xArtx macrumors 6502a

    Joined:
    Mar 30, 2012
    #20
    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 :)
     
  21. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #21
    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." :)
     
  22. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #22
    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
     
  23. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #23


    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.)
     
  24. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #24
    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.
     
  25. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #25
    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.
     

Share This Page