macOS Staying on top of your code

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

B

As mentioned above... Break long code up into smaller modules if possible and document the heck out of it if necessary.

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.

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.

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.