Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Language shortcuts can often be used to make code more concise.

For example, ternary and null coalescing operators can reduce the amount of code, but arguably to the detriment of readability:

In C#:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

is functionally equivalent to:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

but obviously a lot more verbose.

Where do you draw the line when it comes to conciseness vs readability?

share|improve this question
2  
This is a subjective question, someone who implemented something would say his way makes sense, someone reading it would say it makes no sense and another person reading it would say I get it but I prefer another way. This is merely preference. –  Chris Sep 6 '10 at 17:38
6  
@Chris: if it wasn't subjective, it'd be on Stack Overflow... –  Shog9 Sep 7 '10 at 0:52
14  
I think the second version is more readable. –  Vaibhav Sep 21 '10 at 14:57
2  
You are confusing conciseness with terseness. Conciseness improves readability. Terseness detracts from it. –  Ferruccio Nov 15 '11 at 13:56
1  
@ThorbjørnRavnAndersen: The audience for C# code is usually "developers with a C# background". From what I've seen, the consensus here on programmers.se seems to be that you should not avoid using useful language features just because someone might not be familiar with them. (See also: programmers.stackexchange.com/q/101513/33843.) –  Heinzi Nov 15 '11 at 14:06

8 Answers 8

up vote 50 down vote accepted

Both.

Your first example is certainly more verbose, and arguably more explicit... but it also requires me to scan five lines instead of one. Worse, it deemphasizes its purpose - assigning a value to newGuy.Boss.

Your second example may cost me a second if I'm unfamiliar with the null coalescing operator, but there can be no doubt as to its purpose, and if I'm scanning through a larger routine looking for the source of a value, it will be much easier for me to pick this one out.

Now, contrast this:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...with:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

The latter example is again much shorter, but now it obscures its purpose by making tasks triggered by the same test appear to be distinct. Here, I feel the verbosity of the former is justified.

share|improve this answer
3  
Excellent answer! - It's not about verbosity as much as it's about the purpose. –  Damovisa Sep 6 '10 at 5:39
2  
@Damovisa: exactly - the goal of code is communication, and there's no general reason why this shouldn't be done as concisely as possible (but no more). –  Shog9 Sep 6 '10 at 6:07
1  
Learning the null coalescing operator will take more than a second - but if you don't know it, then you should learn it! –  Casebash Sep 7 '10 at 0:35
2  
Ah "??" would be nice in Java. –  user1249 Oct 17 '10 at 10:02
    
Even though the last example is shorter in terms of code, it is actually evaluating boss 3 times as opposed to just once in the verbose example. This is just another reason why shorter code just for sake of being shorter is a bad idea. I think conciseness should be second to the primary objective, whether it is readability/maintainability (for complex code) or performance (for critical sections of inner loops, etc.). In other words, never optimize purely for conciseness -- unless you plan to send your code over a 1bps connection ;) –  user193130 Mar 5 at 23:24

While both are good goals, I'll always side with Readability when forced to choose one.

I would argue that your example improves both readability and brevity. Consider, however:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

as opposed to

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

The latter is concise, but is difficult to read through. The former is verbose, but the flow of logic is clear.

Ultimately, brevity doesn't serve much of a purpose, other than the ability to fit more on the screen. Readability makes it easier to debug, and so should generally be preferred.

share|improve this answer
8  
Proper formatting could easily improve readability of the second example. This is an unfair comparison. When formatted like this, I'm not at all sure it is that bad. –  Steven Jeuris Nov 15 '11 at 14:17

I would say as a general rule never sacrifice readability because of conciseness, but never judge readability based on another programmers lack of knowledge on that subject.

Conciseness and readability are not opposites. Like this answer, sometimes shorter is more readable.

share|improve this answer
3  
+1 for not assuming another programmer's lack of knowledge. In the example given, the second option is only less readable if you aren't familiar with the null coalescing operator. I would never write my code based on the assumption that my co-workers don't know the language syntax. Even if they didn't know what ?? means, if I use it and then they learn it, we've both benefited. And it's not like it's hard to type in "?? operator" on msdn.com –  Tim Goodman Sep 6 '10 at 13:55

I would say I prefer readability, though that sometimes means using concise code. (I.e. ternary for relatively simple conditionals inside a larger conditional block.)

Basically, if it is unnecessarily difficult to understand, don't do it.

share|improve this answer

Readability comes first where it conflicts with conciseness, because code is modified more often than it is initially written. On the other hand:

  1. Syntactic noise and boilerplate code often obscure intentions and thus hurt readability. Sometimes the more concise code is also more readable. For example, think lambda functions or delegates/first-class functions versus single-method classes that implement a single-method interface.

  2. Readability should be assessed based on how easy the code is to read for a reasonably experienced programmer who knows the language and its unique/advanced features fairly well, not some barely competent code monkey who only knows the lowest common denominator.

share|improve this answer

One aspect that I don't think has been mentioned yet: what are your goals?

If all you care about is job security, go for conciseness & compactness over everything else. Skip commenting your code, too.

If you want to be able to easily hand your code off to someone else while you go work on a cool new project, go for readability, clarity, and lots of solid comments.

Note: the above isn't about you personally, @Damovisa; it's for anyone choosing between the two positions.

share|improve this answer

There is one thing that the verbose version has as an advantage.

It has more lines, and most debuggers are line-oriented! It is very hard to set a break point in the middle of an expression, but it is usually trivially simple to set it inside a block statement.

In other words, which one would you want to see in your editor if you want your debugger to kick in when boss == null ?

(That said I like the ??-operator)

share|improve this answer

Readability should come first, long-term most people spend most time modifying or extending existing code - readability is a big part of maintainability.

That said, conciseness is something which can contribute towards readability. For example, in your question the second snippet is both more readable and more concise.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.