Staying on top of your code

Discussion in 'Mac Programming' started by barenature, Nov 26, 2010.

  1. barenature macrumors newbie

    Oct 11, 2010

    Even though I have been programming for quite some time, a problem I run into every time again is that I get lost in my own code from the moment the project has crossed a certain scope.

    How do you stay on top of your code? How do you get a clear picture that tells you exactly which object has a reference to another or how process x unfolds in your application? Do you use only comments (lots of them) or do you write everything down using a notepad or a whiteboard?

    For your information, I do clean up my code and use comments. I am just wondering if there are tools out there that help me with this task.


  2. balamw Moderator


    Staff Member

    Aug 16, 2005
    New England
    I find version control (CVS/Subversion/Git) to be a very useful tool in that even if there is only one contributor to the code. If nothing else it helps you trace how your code got to that point.

    I also find it very useful to KISS keep it small stupid. Focused code modules that are short and to the point are much easier to stay on top of than long rambling code even when that might be more efficient performance wise. That means breaking out sections of code into helper modules, etc...

  3. wpotere Guest

    Oct 7, 2010
    As mentioned above... Break long code up into smaller modules if possible and document the heck out of it if necessary.
  4. gnasher729 macrumors P6


    Nov 25, 2005
    1. Methodnames that say exactly what a method does. Quite easy to achieve in Objective-C. I should be able to guess exactly what _your_ method call does without having read the source code.

    2. Self-contained objects that do one thing and do it well.

    3. Blocks in 10.6 help cutting down the number of helper methods that you need, especially for multithreaded apps.

    4. "Refactor" is your friend; easy to change names to something that makes more sense.

    5. Use Objective-C 2.0 features (properties, iterators) to cut down on lines of code written.

    Just a few things.
  5. barenature thread starter macrumors newbie

    Oct 11, 2010
    Great suggestions! Most of them are familiar, but I guess I should make an extra effort to better implement those in my workflow. I haven't used version control yet (mainly due to the fact that I am not familiar with it), but I think I should take a look at that soon.

    What I am actually looking for in particular, though, is a way to build schemes like you can make mind maps, the so called object graphs (if I'm not mistaken). Do you use such graphs and do you simply write them down on paper or a whiteboard?

  6. Catfish_Man macrumors 68030


    Sep 13, 2001
    Portland, OR
    What I tend to do is push chunks of functionality out (conceptually at least, sometimes literally) into libraries. Then you can define an API boundary, write tests for that API, maybe even document it, and then treat it as almost a separate project.

    The key is to figure out where to draw the API boundary; my rule of thumb is that anywhere there needs to be a two-way interaction (like a calls a method on b which calls another method on a, not via some sort of explicit callback system), both sides of it need to be on one side of the API line.
  7. firewood, Nov 26, 2010
    Last edited: Nov 26, 2010

    firewood macrumors 604

    Jul 29, 2003
    Silicon Valley
    That's what code structure and OOP were designed for (at least one of the main reasons).

    This is good, because you now realize that you will soon forget what you were doing when you wrote any line of code. So start writing stuff that you can plan on forgetting right after you've debugged it and checked it in.

    Start breaking your code up into objects, with well enough defined and self-documented interfaces so that it doesn't matter if you forget what's inside. When that starts getting hard to stay on top of, break these objects up into bigger groups of code objects, making these bigger groups again with well defined interfaces. Then you can start forgetting what's inside huge amounts of your code. Rinse and repeat and you have done what large companies do with projects so large than even lead programmers may have no idea what 90% of the other programmers on the project are doing, in any detail, yet still manage to create stuff that works (well enough).

    The goal is to make the maximum amount of your own code forgettable (as if it were written by a (good) subcontractor of a subcontractor of yours in China/India). Then any "mind map" or graphical doc stuff becomes far simpler, with less objects and arrows, etc.
  8. barenature thread starter macrumors newbie

    Oct 11, 2010
    Thanks for the replies. That is solid advice and I'll keep it in mind. At the moment, I am mainly working with Objective-C, but this obviously applies to any programming language that is OOP centered.

    Looking back, when I was doing quite a bit of PHP programming, I can't believe I was not thinking in objects. I know it's not always necessary to use an OOP approach, but once you get the hang of it, it seems hard to go back.


Share This Page