Spartan Programming

blog
182

name. When it comes to variable names though, I disagree, I’ve gone
the opposite way because I think it improves clarity, avoids errors
and allows me to use my IDE as it was designed.

I sent the link to the rest of my group here, and that was the most contraversial part for us as well.

Its possible that part of the problem is just confusion on our part. There’s no explanation for short names technique, and the link is broken. Someone more of an expert in wikis than I hacked the address manually and got a look at the page, but I’m holding out for it to get fixed (hint. hint).

What we came away with is that if it is a reaction to names like Electronic_Warfare_Tactile_Subsystem.Cockpit_Radio_Aids_Tacan_Package.Tacan_Output_Bytes_Written, then we’d agree. If instead it is an affirmation of names like fgwios (the gross weight of the aircraft, as a float, formatted for the Instructor Operator Station), I’m afraid we part ways here.

183

To Paul Schirf: I am glad you liked the final version (again, I am not sure how we should go about quantifying liking…).

The point here, which I should probably have stressed better is the following. Terse names, that is one or two letter names, make more sense if the context is small. Consider for example identifying an individual person. Within the small family cycle, a one syllable nickname would do. In a classroom, you may need to use the first name spelled in full: Paul. When the individual is part of a larger audience, say, participants in a forum, you may need to write Paul Schirf, and if you need address this individual among all citizens of a large state, you may need to write: PaulSchirfMaleOfPalmSprings.

The point is the following: the smaller the scope, the shorter the name. Conversely, if you strive for short variable names, you will be gravitating towards smaller modules.

There is another point to make here (eventually I will add this to the wiki): in the course of decomposition, you often come up with small, yet general modules. These modules often make terse names even more necessary.

In the Paul Schirf example, suppose you have a module with code designed to serve as back door of an application, e.g., by testing if (user==Paul Schirf) { do lots and lots of special things }.

Now, in decomposing the body of the conditional, one may come up with a small sub module designed to send a birthday greeting by email to the individual. I would expect a signature of the sort of,
congratulate(Person p)
to that module. Conversely, if the same code was inlined into the main module, you would more inclined in using a verbose name for the user to congratulate, by writing e.g.,

User backDoorUser = …;
Message congratulation = …;
send(congratulation, backDoorUser)

The point here is that the strive towards general, non descriptive names, is stimulates and is satisfied by good modular decomposition.

PS.
Others here may suggest using congratulate(Person person) as signature for the submodule, i.e., naming the parameter person rather than p. I am interested in understanding better what makes people prefer the more verbose version in such a case.

Yossi

184

T.E.D. : Would you like to help in revising the C example? Would you mind if I used your suggestions?

I’d probably like to help in revising all the code in the world, but I don’t think I have that kind of time. :slight_smile:

As for using my suggestions, that’s what they were made for.

The way I see it, we are all in the brotherhood of software developers here (female readers included). It is our moral obligation to teach and learn where we can, and to try to leave behind code for our fellow brothers that come behind us that won’t cause them unnessesary grief and time at work away from their loved ones. Our hope and prayer is that those who write the code we read will do the same. So rest assured that I’ll be using any ideas I get from you all without shame.

185

Interesting that people here mention C++. I first used the term Spratan Programming in the context of C++ - and even gave a tutorial on the method in the TOOLS USA 1996 conference.

(believe it or not, there is an acronym behind the term)

The Wiki page was written to help my amazing students train with the method.

186

While the smaller code sets create more understandable small variable names, they only do so because our brains can maintain contextual understanding across a few lines. That doesn’t mean the small variable is more understandable; it simply means it can be understood.

private static MimeBodyPart makeBodyPart(final File f) throws MessagingException {
final MimeBodyPart $ = new MimeBodyPart();
final FileDataSource fds = new FileDataSource(f);
$.setDataHandler(new DataHandler(fds));
$.setFileName(fds.getName());
return $;
}

Is this really more readable than?

private static MimeBodyPart makeBodyPart(final File file) throws MessagingException {
final FileDataSource filedatasource = new FileDataSource(file);
final MimeBodyPart result = new MimeBodyPart();
result.setDataHandler(new DataHandler(filedatasource));
result.setFileName(filedatasource.getName());
return result;
}

187

Rhywun, tk., and Graham Steward: Using a return object to enforce
single return is cargo cult programming. You’re accomplishing nothing
and you’re doing it because of an old misunderstanding of Dijktra’s
and Hoare’s Structured Programming. One principle was one entry
point, one exit point but as soon as you have a changing return
object, you’ve already violated that principle (for all intents and
purposes) and you’ve reduced clarity.

There’s nothing goto about early returns, quite the contrary.
(Unless you count lambda as the ultimate goto.)

Swedish Code-monkey: What is readability? I see this word, I hear
this word but there’s never a definition. Spartan programming is
clearly defined with a number of metrics and practices, unlike
readable code which in my experience usually turns out to be a word
for redundant, overly explicit code.

Danish Rumani and j450n : Blocks are for more than one statement; i.e. when
you’re using side-effects or state. If you’re adding additional
side-effects to a conditional clause you better well be on the look
out for bugs, since that’s something that should be done carefully, if
at all. To my eyes, every {}-pair means Here be side-effects!
similar to the exclamation marks in Scheme, and I use them
as sparingly. In your PunishTheKiller example, you’ve added
state-changing functionality.

188

Well, maybe it is…

I still prefer the idea of making this an object. In doing so, the result is far more readable.

Daniel hit the nail on the head when he said EXPLICIT getters and setters are noise, not signal. The language should support object.var = expression;

I also personally dislike case sensitive languages. Context in natural language rarely changes based on case. Oh sure, there are exceptions… and they obscure meaning.

189

Paul Shirf: Yes.

190

What is readability?

I’ve been in code reviews were non-coders were included to check for code readability. The idea is that, if the context of what is taking place in the code is clear to a non-geek, then its code that can be debugged easier in the future by coders who have incomplete understanding of the code outside of the routine they’re looking at. And don’t say that this isn’t one of the benefits of OO! Encapsulate context/meaning!

191

This looks pretty darn close to what McConnell advocates for in Code Complete, doesn’t it? If not explicitly (although using enumerated types and case statements this way is explicit) at least philosophically.

192

lesscode.org

gonna leave it like that, but http://lesscode.org/about/ says it succinctly: use less code to get more done. It focuses more on the solution as a whole, rather than individual techniques in various platforms. Sometimes the bigger win is not to refactor a function or a file altogether, but the platform altogether.

193

@Bill
And I will use it(Williamprogramming) to write bad code.
Then what?

194

Now the time has come for me to conclude:
(1) It depends.
(2) Its all about trade offs.

195

I usually apply the DRY principle on my code.

Although it is not actually the same as spartan programming (how much I like this name !), I think it shares the basic concept.

196

Not to kiss-up to my professor, here’s another way to examine terse variable names.

First, variable names are actually used for two purposes:

  1. Specifying a name to access the area in memory (which isn’t mandatory in C++ signatures, but is in Java interfaces)
  2. Documenting the meaning of that variable

Just as you should prefer writing code that explains itself without comments, so should you strive for short and well-written methods that describe the meaning of the variables they use. An extreme case of this is Java’s System.out.println(), where an entire group of methods have the same meaningless argument name x.

Looking at this the other way around, terse variables are a kind of litmus test for method complexity: if you have many long- and descriptively-named variables (which are a mental-load on the person reading the code), it might mean that you should break-down the method.

And as for shrt vars tht r hrd 2 read, @RedGreen, according to this style, variable names are either one-letter or the full word (plus s for collections). Never shortened names like you suggest, not even msg; either message or m.

197

The Spartan programming methodology dictates minimization of horizontal complexity […]. This is because it is believed that horizontal scrolling is even more intellectually demanding then vertical scrolling. Further, it is believed that deep nested control is difficult to understand.

This guy is dictating to me based on a set of beliefs? Where’s the evidence? Sounds like religion to me.

198

@Sunnan: Rhywun, tk., and Graham Steward: Using a return object to enforce single return is cargo cult programming. You’re accomplishing nothing and you’re doing it because of an old misunderstanding of Dijktra’s and Hoare’s Structured Programming…

No cargo cult here. I can’t speak for the others but I’m doing it for two reasons (neither of which have anything to do with Dijkstra):

  1. it is the preferred approach in my company’s coding standard. The standard contains wisdom from 20 years of writing code and sticking to it keeps our code consistent.

  2. I’m also a member of the code review team and I know from my own experience that I find it easier to mentally parse and trace possible code paths in routines with a single return point.

Also, as I said before, I do sometimes use early-returns for establishing pre-conditions at the start of a routine (e.g. if param1 is null then return -1) or in very short routines (up to about 10-15 lines) where readability won’t be affected. But generally I prefer to keep them to a minimum.

For the record, Code Complete 2 (Chapter 17.1, Unusual Control Structures) has the following advice, which I believe fits well with my approach:

  • Use a return when it enhances readability.
  • Use guard clauses (early returns or exits) to simplify complex error processing.
  • Minimize the number of returns in each routine.
199

Personally my only reasoning for using single return points is when some memory is allocated or some library/structure/function is initialised that must be shutdown before exiting the function (e.g. fopen/fclose, CreateWindow/DestroyWindow etc…).

Here I also use that most heinous of all evils the goto statement. Its pretty much the one place I will use it…

In other situations I don’t find it helps… it just makes an extra step when reading code, which may or may not involve using Find or a lot of scrolling about in a file in order to track what I think the code should be doing… I like to avoid these sorts of constructs, as much as they have little or no effect on the compiler or program output.

200

@Jheriko:

So (based on your posts):

you leave member variables as public to save writing accessors; you don’t use foreach or other language constructs that hide code; you avoid using existing frameworks; you write your own versions of basic library routines like strcat(); and you use gotos.

Man, I’m glad I don’t have to review your code! :slight_smile:

201

Rather than Spartan Programming, I’d call it Laconic Programming. I know for a fact that the Spartans used COBOL.