How 'terse' is too terse? -- Practical guidelines for expressing as much intent in as few characters

Question

First, I love writing as little code as possible. I think, and please correct me, one of the golden rules of programming is to express your code in as few of character as possible while maintaining human readability.

But I can get a little carried away. I can pack three or four lines into one statement, something like

$startDate = $dateTime > time() ? mktime(0,0,0,date('m',time()-86400),date('d',time()+86400),2011) : time();

(Note: this is a notional example, consider it pseudo code)

I can comprehend the above code when reading it. I prefer 'mushing' it all together because having less lines per page is a good thing to me.

So my question: When writing code and thinking about how compact or terse you can express yourself, what are some guidelines you use? Do you write multiple lines because you think it helps other people? Do you write as little as possible, but use comments? Or do you always look for the way to write as little code as possible and enjoy the rewards of compact statements?

(Just one slightly off topic comment: I love the Perl one-liners, but that is not what I am talking about here)

Answer 1

Brevity is only a virtue if it leads to readability.

[O]ne of the golden rules of programming is to express your code in as few of character as possible while maintaining human readability.

I would rather say:

One of the golden rules of programming is to maintain human readability.

If the shorter code is the most readable, by all means use it. If the shorter code is only shorter, but less readable, rewrite it.

Answer 2

The goal is not terseness, in my opinion, but efficiency and readability, and along with the latter maintainability. Smaller methods are a good thing - single-letter variable names to shorten your code (except in certain relatively rare instances) are not. I'd happily split your example over three lines if I felt that it made it more readable.

As for comments, I try to write code that is as clear as possible without comments. I try to only use comments for API definitions and to explain why something is done in a non-obvious way.

I think this quote by Dijkstra, in a talk title The Humble Programmer, is somewhat appropriate:

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called "the one-liners". It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question "Can you code this in less symbols?" —as if this were of any conceptual relevance!— or he just asks "Guess what it does!". From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.

Answer 3

I'm in favour of readability.

Ternary conditionals are fine IMO - they save a lot of useless code. But a complex mktime statement like that I would probably split into more lines than just two:

$month = date('m',time()-86400);   # Explanation here
$day =   date('d',time()*2),2011)  # Explanation here
$year =  2011;                     # Because the world ends in 2012

$startDate = $dateTime > time() ? mktime (0,0,0,$month,$year,$day) : time();

Having readable code without bloat is an art, and there are many interpretations. If in doubt, I would go with the bloat rather than a compact statement that takes 15 minutes to understand.

Answer 4

"one of the golden rules of programming is to express your code in as few of character as possible while maintaining human readability"

That last clause is the kicker.

Generally, code readability is about a broader population than you. If only you can understand the code, then it's going to be a major chore for anyone else to work on it. Which may be great if it's your special pet project, perhaps something else entirely if you're trying to work on something else.

I try to to write code using constructs that are commonly accepted (either in general, or at my particular workplace) so that it is easier to understand the codebase. If the people you work with are used to a similar terse style, use that. My guess from your comments is that you are on the extreme end, in which case I'd dial it back a bit.

In your example:

• What are the magic numbers in there?
• Is there a comment ahead of that block of code that explains (in a few words at least) what it's doing?
• Do you really need to make 4 calls to time() when a single assignment first would be computationally less expensive?

Answer 5

1. If it is not readable, it is much harder to know if it is correct.
2. If it is not readable, it is much harder to find what is wrong.
3. If it is not readable, it is much harder for someone else to learn.
4. If it is not readable, it is much harder to understand what it is SUPPOSED to be doing.

All the above items cost time, and productivity. If you are working for a company, it also costs $$$.

Answer 6

The easiest way to know 'how terse is too terse' is to ask your colleagues to briefly review your real code. They'll likely be more than happy to tell you if the code is comprehensible (especially if they'd ever be asked to maintain it).