It seems that I have the same age as Jeff Atwood, but somehow not, when I read his latest post. Somehow I feel "been there, done that", because I would almost have agreed with him 10 years ago, while still being a freelance programmer, helping out in various programming teams. However, today I'd definitely say that maintainability is much more important than most programmers want to acknowledge.
Most programmers spend most of their time maintaining code, not writing new code. They may spend time on maintaining their own code - but it's still about maintenance. And actually, they spend much more time per SLOC when doing maintenance, than when writing new code. In other words, in order to be really productive, it's the maintenance part that needs to be optimized, unless you're doing a quick and dirty application that nobody is going to use (yeah, right!). The perfect source code is when it works perfectly AND cannot be easier to maintain. This includes simplicity, of course, but it also includes comments, understandable variable names, well defined context and well defined invariants.
5 comments:
... and inherent readability.
My biggest problem with C# is that every time I sit down convinced that NOW is the time to really get to grips with it, I rapidly lose interest because the language is so damned ugly.
You have to work hard to write readable code, and once code has any decent length of life behind it, it quickly becomes an incoherent mess of attributes and insanely long qualified references.
It's a language designed to be spewed out by tools and interacted with through wizards, not be written or read by mere humans.
Which is why Pascal remains my language of choice. With Pascal you have to work hard to make code UNreadable.
And much of the recent language "innovations" in C# particularly serve only to further REDUCE the readability of code, under the smokescreen of improving it.
If when I look at code I cannot see what it does, then it is not readable. The aim of things like LINQ etc is to allow me to see the INTENT of the code. But bugs/problems never stem from INTENT, only from actual ACTION.
I can see the INTENT from the spec.
I can only see that actual ACTION taken by the code by reading the code. If there is some problem in the translation of INTENT to ACTION, then ONLY being able to see the INTENT doesn't help.
It helps CREATE the code, but is going to get in the way of maintaining that code in the long run.
So I guess you can put me in the "Old School" camp too.
:)
Hi Lars,
I think I understood your statement but am not sure. I believe you're saying that over minimalism degrades maintainability. Am I right?
(BTW, If this is your intention then I strongly agree.)
Nonetheless, considering Jeff Atwood's latest post, I think the kind of minimalism presented there is counter-productive: if you give me a method I can mess with it for ages, tweaking it a bit here and a bit there trying to save one more line. But this is practically a waste of time. It is much more important to invest in optimizing the signature of the method/the interface of the class: Getting to a simple, intuitive and explicit interface is much more important than reducing the line count/token count of a method.
@Jolyon Smith
Using statements help tremendously.
Attributes are used rarely. Except with some open source frameworks that seem to love them alot.
Readable code is easy :)
@Itay: I generally dislike "-isms" because they set up rules that people try to apply without understanding the preconditions that need to be met.
I totally agree with you that interface are more important for readability than implementations.
Although I currently spend most of my time in C++/C# land, I really miss the interface/implementation separation of Pascal-based languages. It's just so much easier to get a quick overview of what a class does by looking at the interface section and jumping back and forth between interface and implementation by using a simple keystroke.
Post a Comment