Spartan Programming
by
Jeff Atwood was pleased to find that his coding conventions, the ones we all settle into, have been tending towards those of a style of programming called Spartan Programming. Which is minimalist programming, as in "a spartan lifestyle". Check his post out for a more in depth explination but suffice to say the aim is to reduce complexity in any way possible.
I've got to agree that more and more I've tended in that direction too. I don't remember the last time I had more than a handful of conditionals or loops in a method. My methods are terse and accomplish one thing, sub tasks are split out into other methods. It's come very naturally, but it has taken time. I don't think it's something you can be taught, or learn. It's definitely a practice thing.
One aspect of Spartan Programming where I disagree is with the terse variable names. I think they could end up introducing more accidental and avoidable errors. They lessen the utility of some key IDE features. And generally would just make my life harder, so I've gone the other way. Once upon a time I would happily create the following code:
public void sendMessage() {
MimeMessage m = new MimeMessage();
m.setBody("This is a test");
m.send();
}
These days I try to avoid calling variables things like m and prefer to call them what they are:
public void sendMessage() {
MimeMessage message = new MimeMessage();
message.setBody("This is a test");
message.send();
}
I know the arguments and logic:
- The method should be simple enough that the variable name m is clear enough.
- The shorter name reduces complexity and therefore errors.
- Less characters means lines don't get too long
Of these three the third is the only one I really buy though. Long variable names and too many characters on a line can push some stuff too far to the right potentially hiding errors or overly complex code; but it's an edge case and there are other ways to solve the problem.
While true that in a short minimalist method a variable m would be clear enough, a variable called message is equally clear. The shortening doesn't gain anything in clarity. The argument for less characters reducing errors in the era of modern IDEs doesn't wash with me either - My IDE tells me of I mistype a variable and auto completes them furthermore by typing actual words I actually improve the accuracy even more.
Shorter names on the other hand can tend more towards a crowded namespace and can result in properly typing the wrong variable. This is especially a problem in a weakly typed language.
Consider the following:
function sendInviteMessages(n)
for i = 0 to n
Set m = Server.CreateObject("MimeMessage)
m.Body = "Welcome to our fancy new site!"
m.Send
Set n = Nothing
next
end function
What you see here is something that wouldn't happen, or not as often with a variable name like number instead of n and message instead of m. Worse still, depending on the language and how it treats null variables it might even pass a quick test with a single address and appear to be working!
The one place I totally disagree with the terse variable naming conventions though, is the method parameters. That actually makes life harder when working with code completion. Which is easier to follow?
[[posterous-content:eGAIahqgzytkaCBzAqDi]] [[posterous-content:BytBtkkrvcjwhyJbrGHq]]There are plenty of other code completion and helpful shortcuts in a modern IDE where the parameter names are used to make our lives easier. All of which lost, with no real gain.
I'm not arguing that variable names shouldn't be terse and sensible. Going back to the first example the following is just stupid and is far worse than using just m, it's practically illegible and very difficult to just eyeball the code to see what is going on.
public void sendMessage() {
MimeMessage theMessageToSend = new MimeMessage();
theMessageToSend.setBody("This is a test");
theMessageToSend.send();
}
Other times I go the opposite way and have adopted conventions for making some variables extremely terse. InputStream and OutputStream variables for example I always call is and os. So I do try and be as terse as possible, but never terseness at the expense of obviousness of intent.
While I agree with most of the practices and like Jeff was nodding along as I read about Spartan Programming, there are a few I don't fully follow and some I'm against. In the end though I tend to agree with his assertion that Minimalism isn't always the right choice, but it's rarely the wrong choice as long as it's not at the expense of clarity of intent.
Subscribe via RSS