I've been so busy this week that I didn't have time to write my journal until Saturday, and then there seven to write. But somehow I've written the previous six, so now this is the last one. It's for Thursday because I tend to jump around when I have several entries to write. Just whatever I think I want to write about, then I have to pick an appropriate day when it happened, or a spare day if it doesn't tie in to a time.

Anyway, I want to write about my programming practice. After a few years of writing code and reading about various software practices. After looking at other people's code and wishing they hadn't done this or that. I have developed a certain set of things I do when I write code. It works for me and I don't claim that they are the best practices or even good practices, but the ones that I do tend to follow, if I remember to. The following will probably be specific to Java programming, since that is what I'm doing now.

The first thing about code writing is to write clearly. Don't misspell variable names and other identifiers, as that is a nightmare to debug. Use the standard Java naming conventions (which are the Mac naming conventions except they start out with lower case). Write Javadoc comments as you write your code. Don't comment afterwards as you'll forget to do it. I tend to use five asterisks to mark code that is temporary or hacky and should be fixed later. Probably should use another symbol since people use asterisks to demark delimiter lines when printing.

Everything has an interface, everything has a factory. I've settled on many interfaces and one package factory. This means that other people can code to the interface and factory and that the implementation can change freely. Make sure your code uses the factory and interfaces. I don't comment interfaces with Javadoc, that's for the implementation. This keeps the interface clear and can be a useful reference to see what methods are in a class. Put package variables in the factory, make sure the factory is abstract. Never extend a class if you can help it. I always use instance variables and pass method calls to them instead of extending a class.

It's a good idea to write your real documentation as you write the code. I'm talking about the Programmers' and API manuals. This is a rather onerous one, and one I don't do much. I usually write up the specifications and theory if I have time during the design phase, but once I start coding I don't write any manuals. The only time I've done it is when my code is going yo be used by other people.

Code a few things and make sure they work. Then code more and make sure it all works before continuing. This is an iterative implementation approach that I've read about and tend to do myself. You have less bugs and less places for bugs so they're easier to track down. As you implement functionality you can make sure that you're going in the right direction. And it's more satisfying to know that this works and that works. Much harder to code everything and then try to test.

This does mean though that you'll code some patchwork stuff that will be thrown away and replaced later. The extra time taken doing that is offset by less debugging, in my opinion. I'm pretty scattershot about thinking ahead. I try to implement each step in a general way, such that it'll keep working when I add more code. But there are many times when, to add some functionality, I have to tear down a subsystem and rewrite major parts of it.

There are also times when I've coded something in a general way, trying not to hard code values and write utility methods and generic methods to do the real work. And then later on I find out that all this infrastructure I've written can be used to implement this later functionality so it's a simple addition. Writing code in a generic way is something you'll develop. It starts out specific, then you implement something else specific, then you realize there's a general case and combine the two implementations, then the third implementation neatly adds on.

So that's a capsule essay on how I code. The most important part is iterative coding. It keeps me sane to know that all this works, so if it's broken now it's because of this. And it's also invigorating to see that you are getting concrete things done.