The Ancient Art of Programming

It seems that I am not the only one preferring a domain model above a relational model. Martin Fowler wrote:

This may have something to do with the fact that while SQL works well for databases, we don’t have the equivalent for in-memory processing. Thinking relationally is one of the things I find interesting about ADO.NET, yet again I see many people who don’t want to work with datasets in a relational style.

This certainly applies to me.

Everything written by Joel Spolsky is worth reading. Not only does he hit the nail on the head; he does so in an extremely humorous way. His latest piece, about software pricing, is no exception:

The reason I’m so excited is it looks like if you plot price against profit, you get a nice curve with a big hump in the middle! And we all know what humps mean! Humps mean local maxima! Or camels. But here they mean local maxima!

Man, I wish I could write like that.

This is the fifth post in a series about writing code for my co-workers. Here are parts one, two, three, and four.

You are your own coworker!

In my previous post, I wrote that code should be so clear and navigable so that your coworker could take over at once. The beauty of this practice is that you don’t do it for just your coworkers, but also yourself.

That is because after spending two months on another project, it doesn’t really matter who wrote the code in the first place. You have forgotten the pesky details and clever hacks; it might as well have been writing by somebody else altogether. If you wrote clearly, you will find your way after a couple of hours.

This is the fourth post in a series about writing code for my co-workers. Here are parts one, two, and three.

Coding conventions

For the past two weeks, I have been posting about writing code for your coworker. The idea behind this is that if you are hit by a bus this afternoon, your coworker should be able to take over your work tomorrow morning. Your code should be so clear and navigable so that he could take over at once.

This is also where coding conventions come in. The objective of coding rules is to reduce confusion among the developers. The key to that is consistency: consistency throughout a project, between projects and between authors. A coding standard will contain stuff like:

• Where to put your braces,
• How many spaces in a tab,
• Keep tabs or replace them with spaces,
• What is the standard preamble for all your source files (i.e. the copyright etc.),
• Your naming conventions,
• What is the order of the members of your class (i.e. variables first, then the constructors, followed by properties, etc),
• etc…

The choices you make in the standard are not really important: code will not perform better or worse because of it. You can have a field day discussing it, though, because everybody has his own opinion about brace placement, and every developer thinks his way is best. At a former company, I once spent one week talking about this stuff. That’s why it is best to let one person create a coding standard, and let all developers pledge allegiance to it.

What is important, however, is to adhere to the standard. Again: you’re doing it for your coworkers: they can find their way and fit in easier with a coding standard.

This is the third post in a series about writing code for my co-workers. Here are parts one and two.

Navigability

In the previous posts, I wrote about code naming and clarity. Another factor which makes your code easier to maintain is code navigation. What I mean by code navigability is how easyy it is to find your way around the various classes contained in the project.

In Java, good code navigability is enforced by the compiler. That is:

• The name of the source file must be the same as the name of the class defined in it, and
• The directory structure where the source file is stored must reflect the package of the class.

So, for example, MyClass needs to be in a file MyClass.java, and if MyClass is declared in the package com.whatever, the file needs to be in the directory com/whatever. If you do not meet these terms, the compiler will spit out an error. (Note: if I remember correctly, this used to be a warning in the JDK 1.0 days, but I am not sure).

Unfortunately, .NET does not enforce these conditions. This means that you are able to save your code in any file and/or folder you want, and this have disastrous effect on navigability. You can still use your IDE of choice to find whatever you’re looking for, but it isn’t as simple as it could have been.

In order for your coworkers to find their way in your code, the best thing to do is simply to make the file name and type name identical, and to reflect sub-namespaces with subfolders. No matter how simple the type: even a two-valued enum gets its own file.

Note that with C# 2.0, we are going to get Partial Classes, and code navigability is going to get even worse: you have to find out in which of the two (three? four?) files that make up a class is that particular method you need to edit.