No, I'm not talking about where the brace brackets go! Coding guidelines are so much more than style guidelines. One of the things that sets me apart from many other developers I know, and especially the authors of code I am asked to fix, is a drive for simplicity. For me, that comes down to three things:
- Start by solving the problem you're actually facing, not some enormous superset of it
- Write the straight ahead way first, then adjust for the exceptions and strange corner cases
- When it's all working, and every time you touch it from then on, look it over to see if you can make it simpler.
That last one is the one so many people seem to skip. Then later when I come along and read the code, I see how it could be simpler, but I hesitate to change it. They must have done it this complicated way for a reason, I think to myself. It can take quite a long time to prove to myself that no, they just settled for 'working' and ran away as fast as they could, leaving this mess for someone else to sort out later.
A mentoring client gave me a pointer to an article ostensibly on Coding Guidelines which is as much philosophical as anything else. I like it. The rules are:
- Make your code look like other people's code.
- Use the simplest design possible.
- Don't re-invent the wheel.
- Document your code.
- Keep security in mind.
- Work in increments.
- Work in iterations.
- Have your code reviewed.
- Don't stay blocked.
- Do unto others as you would have them do unto you.
There are no false notes in this list and I endorse this set of philosphies whole-heartedly.
Kate