In C#, with extension methods, you can replace this line of code:

TimeSpan interval = TimeSpan.FromMinutes(4);

with this one:

TimeSpan interval = 4.Minutes();

Extension method being:

public static TimeSpan Minutes(this int minutes)
    return TimeSpan.FromMinutes(minutes);

The second example is interesting because of the extension method on the integer literal, which is valid, but looks strange (even more so because adding a period after a integer literal has two different meanings: becoming double literal and member access). The second example also reads almost like english (even though the first one does as well albeit in a different way).

Is it a bad practice to use language features in such way as to increase brevity and readability, but "abusing" the language? (I prefer answers that deal with WHY you consider one better than the other, and not only WHICH ONE you prefer.)

Personally I find the second way more like the usual object-oriented way of thinking in which you state the object first and then access its member operation to perform.

Similarly to how we do with ToString:

StringBuilder str = new StringBuilder();

// ... append something to the builder

String result = str.ToString(); 

and we don't do

Strong result = String.From(str);

Of course, one could argue that this is simply how the API/Framework was designed.

Additional note:

This can also be stretched toward some other examples of achieving brevity:

String str = String.Format("{0} + {1} = {2}", op1, op2, op3);

changed to:

String str = "{0} + {1} = {2}".FormatWith(op1, op2, op3);

1 Answer 1


Is brevity in writing code beneficial when it requires using language constructs in a strange way?

Hell no.

Brevity is not a desirable trait. The time it takes to type in code is not a meaningful thing to optimize, since we so infrequently write code as opposed to read/debug/modify it. The time it takes the parser to read your code (or the size it takes on disk) is trivial.

Readability is a desirable trait, but it does not necessarily follow that brevity leads to readability. After all, the time spent understanding what we read isn't mostly spent on seeing characters, but parsing them into meaning. Doing weird things will take far longer to understand in general. This is well known as the Principle of Least Astonishment (or Surprise) in design circles.

Now sometimes, using weird constructs makes things more readable/efficient/robust once people learn them and get used to them. That is a trade-off like any other worth evaluating. But your examples all make things hard to read to do nothing more than save a few characters.

  • 2
    So much this. "Clean and readable" wins over "short" every time. Obfuscated code is often exceptionally brief. Commented Jan 26, 2015 at 15:10
  • 1
    Very much this. Obvious but non-standard will still take longer to read than standard but slightly longer, because the user will have to stop and think about the code, rather than just reading it. Good code can be read almost like a to-do list.
    – Jon Story
    Commented Jan 26, 2015 at 15:45
  • The one important thing in your answer that is IMHO missing is a clear statement that we should try to achieve both readability and brevity. Code which is more verbose is not necessarily more readable.
    – Doc Brown
    Commented Jan 26, 2015 at 21:02
  • @DocBrown - You're of course right that verbose code is not necessarily more readable. But I don't believe that you should strive for brevity at all. You should write clean, readable code. If it ends up brief, great. If it ends up verbose, great. Human/programmer tendency towards laziness and programmer tendency towards efficiency will drive things towards brevity naturally. More often than not, when someone strives for brevity you end up with terse, unmaintainable line noise.
    – Telastyn
    Commented Jan 26, 2015 at 21:10
  • 1
    Not that disagree to you, but according to this study, brewity in code might have a bigger positive influence on maintainability than we all think: leanway.no/code-is-the-problem
    – Doc Brown
    Commented Jan 27, 2015 at 10:35

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