Spartan?

A colleague directed my attention to an essay on 'Spartan Programming'. Initially, I was interested. 'Spartan' expresses an idea which should make for good software: simple, not complex; sparse, not prolix. But having actually read the article, I find I disagree with quite a lot of it. I think it's missing the point.

Let's start from my basic position, which is the same as it has always been: the primary purpose of source code is not to communicate with the complier nor to direct the computer. The primary purpose of source code is to communicate with the programmer who is to come after us,, the human being who actually has to read the code and understand what was intended. Everything which helps this is good programming. Everything which hinders this is bad programming. Period.

While unnecessarily long and complex variable (function, method, class) names ought to be penalised, reducing variable names to 'x' and 'y' should also (normally) be penalised. 'minimising character count' does not recognise this. Names need to be understandable, distinctive, memorable. It even helps if some of them are funny - it stops the person reading your code from getting bored.

Minimising character count also means minimising comments, and that’s completely the wrong thing to do.. Diametrically wrong. I have only - ever - known one programmer who in my opinion commented enough, His code was Spartan in the best sense - simple, elegant, a complete joy to read - and adequately commented. Typically, he's now a sound engineer for rock bands. Programmers just do not document enough and in particular do not comment enough - and there is too much code produced in our team where lack of commenting verges on the unprofessional. We have to raise our game here, folks!

'Minimize variability of variables' is just illiterate. If someone doesn't know the difference between a variable and a constant, he has nothing to teach anyone about software design.

Early return is controversial, but I'll always mark you down for it. A function should have just one entry point and just one exit point, exceptions excepted. Again, this is part of the essential rubric 'communicate with the programmer' - a single return makes a function much easier to read. And, yes, anything which returns a value is a function, whatever fancy name the language designers decided to apply to it. Similarly, anything which does not return a value is not a function - no matter what the illiterate language designers think.

I disagree mildly about complexity, too, in the special case of class hierarchies. Deeply nested class hierarchies mean that each class deals with just one problem - it isolates problems and lets you look at one thing at a time. This adds to clarity. And this is why he's completely wrong about 'Minimize accessibility of variables'. Variables should normally only be marked private or final in performance optimisation of finished code. Every class should be designed to be extended.

This example:

http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Class_Once

illustrates so many examples of bad programming that any student turning it in in Software 101 should be failed immediately, and sent to study accountancy instead. It's not merely uncommented, it's also wilfully obscurantist. It does not communicate at all.