C# is verbose. Verbose is good.

C# is verbose. Verbose is good.

  • Comments 10

On ScottWil’s blog recently, Thomas Eyde commented on C#, saying “Basically I think C# is too static, complex and verbose. There [is] so much you have to type which does not add value.”  I am admittedly biased, but I think that C#’s verboseness is a good thing. 

 

On the face of it, being able to express the same idea in fewer lines or characters of code sounds like a useful trait in a language.  But there are a couple of reasons why I don’t think this is as good of a goal as it sounds like.

 

The first is that far more time is spent reading code than writing it.  If writing code in a particular language takes twice as many lines or characters, but this causes the reader to spend half as much time trying to understand it, the tradeoff is very likely worthwhile (since the code will be read more times than it was written).  This is the same argument that is made to explain why it’s important to use descriptive variable names.  Using variable names that don’t carry any connotations forces the reader to follow the entire flow of the variable through the code to understand what it represents.  On the other hand, variable names that carry connotations about their meaning can help a programmer convey information about the variable, so that the reader can just read a snippet of code and have a good idea what it is doing.

 

The second is that tools, like intellisense, can help make the number of characters typed far less than the number of characters of code that are generated.  As a simple example of this, take the following block of code:

 

foreach (Item<T> item in state.Items)

{

  if (item.Index >= item.Production.Right.Count)

  {

    foreach (Terminal<T> follow in Follow(item.Production.Left))

    {

      ActionTable.Add(state, follow, new Reduce<T>(item.Production));

    }

  }

}                                    (233 keystrokes)

 

This can be written in the Visual Studio C# editor with approximately half as many keystrokes as produced characters, by typing the following sequence of characters.

 

fore(It<T> item in sta.I)

{

if(it.I>=i.P.R.C)

{

f(Te<T> follow in Fol(it.P.L))

{

ActionT.A(s,follow,new Re<T>(i.P));

}

}

}                                    (122 keystrokes)

 

Or even better, you could take advantage of code snippets, and write the same code in even fewer keystrokes (“” represents a tab):

 

fore→→It<T>→item→sta.I→

if→→it.I>=i.P.R.C→

f→→Te<T>→follow→Fol(it.P.L)→

ActionT.A(s,follow,new Re<T>(i.P));  (107 keystrokes)

 

Of course, the characters typed in above are clearly unreadable, and so the presentation (and persistence) of these as the original C# program helps readability and maintenance of the code for future readers.  But the end result is that in relatively few keystrokes, a programmer can create code that is verbose enough to be easy to read by the next programmer who needs to modify it.  This gives a sort of “best of both worlds”, which feels like a good thing to me.  What do you think?

Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post
  • The code snippet takes up ten lines and doesn't tell me what it does.
    The verboseness means that it takes more time to work with (more screens, or paper to read) and is more difficult to get an overview.
    It is certainly possible (easy) to write cryptic C++, and this is worse than being verbose, but C++ has (IMHO) a more efficient representation available to it than C# whilst still being useful.
    In other words, C++ allows the code to be verbose, but C# doesn't allow them to be efficient.

    And the keystroke argument doesn't hold water.
    Intellisense is only useful if you don't know what you are doing - if you know what you are typing Intellisense achieves nothing.
    I can type 233 keystrokes a lot more quickly than I can type 122 keystrokes and respond to 19 popup menus.
    I'm not saying that Intellisense isn't useful, but it's not a counter-argument to claims that verbose languages take longer to type.
  • C# is just all right. I come from VB6 so I'm accustomed too much more typing. It never bothered me for the very reason you mention: "the code will be read more times than it was written".
  • Yaytay -
    "The code snippet takes up ten lines and doesn't tell me what it does."
    Agreed, this code block is too detached from its context to be clear on its own.

    "C++ has (IMHO) a more efficient representation available to it than C# whilst still being useful."
    As you point out, it is possible to write some cryptic code in C++, but for the example above, I can't think of a way to write it more space-efficiently in C++, and the naive translation to C++ would use for loops and would then have indexes floating around the code that don't have a real meaning to the algorithm. In general though, C++ sometimes does allow a more compact way of expressing things (primarily using macros), but I contend that this is rarely beneficial to the readability of the code after it is written.

    "Intellisense is only useful if you don't know what you are doing - if you know what you are typing Intellisense achieves nothing."
    My experience has been that Intellisense is useful both for browsing ("if you don't know what you are doing") and typing ("if you know what you are doing"). Anson has a post on this on his blog at http://blogs.msdn.com/ansonh/archive/2004/02/28/81647.aspx . Even for very fast typers, intellisense can reduce some of the burdens of a verbose language. For instance, C# is often chastized for having to list the name of the type twice in a variable declartaion:

    Dictionary<int, string> numbers = new Dictionary<int,string>();

    No matter how fast you type, intellisense will probably improve your code-creation-speed when it offers to complete the second of these type refrences for you after you type the "new ".
  • Hugo -

    "C# is just all right."
    Fair enough.

    "I come from VB6 so I'm accustomed too much more typing."
    Interestingly, most of the arguments I made here probably do apply to VB6 as well. The languages that I consider on the "concise" side of the fence are ones like Perl, Python, Ruby, ML, etc.




  • This reminded me of the obfuscated C competition. http://www.ioccc.org/ amazing programs.
  • On Intellisense:
    I don't see how it can be as quick as fast typing - when I am working I know in my head what I want to see, and then by fingers just get on with - the actual typing is completely subconscious and out of step with the conscious thought.
    In order to respond to menus on screen, no matter how quickly they appear, one has to bring the conscious mind into it - slowing down the overall rate of entry.
    Of course this is only relevant in those few occasions when one knows exactly what one wants to write, but they are the good times :-)

    On compact C++
    C++ does not, ever, get compactness from macros, it gets them from templates.

    I find that things like the STL encourage a more structured, clear and concise approach to coding that, probably, is not inherently down to the language itself (though I do consider templates to still be in a completely different world to generics).
    The problem with your original snippet is that it doesn't say what it does.
    The whole thing should be in a function with a clear name and there is an argument that the inner loop should also be in a function.
    That is extra verbosity that benefits the reader.
    Dictionary<int, string> numbers = new Dictionary<int,string>();
    is extra verbosity that benefits only the compiler.

    I don't dislike C#, or .net, both have a purpose.
    I do find the .net library unusably poor and that puts me off .net as a whole - but that's very definitely another conversation.
  • I don't think it's very useful to define "verbosity" as the number of keystrokes it takes to type something. More accurate might be the number of elements in the AST of a representative program in the language. Whether C# could be called verbose by this measure, I'm not sure -- but I think it's clear that producing a succinct AST is a good thing, and needless clutter ("verbosity") a bad thing.

    With regard to number of keystrokes, your argument is actually similar to what the ANSI Common LISP committee thought, I believe: "verbose is good; long function names (especially in the standard language and libraries) are a not a problem given the existence of a good IDE that can do auto-completion". The problem is that you don't just write code, you also read it -- and verbosity is not always good when reading code. The more verbose it is, the less code you can fit on the screen, and the more work your eye and your brain have to do to figure out what the code is intended to do. Maybe it's a question of <i>needless</i> verbosity -- is the language forcing me to read or to write something in its syntax that I ought to be able to infer for myself? For example, type inference is a win because more often than not, the variable name also gives its type, or the type is obvious from the context.
  • PingBack from http://feeds.maxblog.eu/item_623557.html

  • I can only recognize from my experience of VS that entering the same amount of code while typing only half as much is a good thing.

    But it is the answer to too much indulgent a question.

    To be more accurate, the initial sentence should be "There is so much you have to read which does not have value".

    Typing is just the way you enter the code: it is important, of course, all UI issues are. But, when talking about the language, the verbosity is an issue when you try to read the code, not write it.

    Verbose is bad. Verbose is garbage filling up my brain's limited capacity.

  • PingBack from http://besteyecreamsite.info/story.php?id=1550

Page 1 of 1 (10 items)