There seems to be a movement towards writing less code. I see it all the time.
- You have C and C# evangelists who can't stand Pascal because they can do in two key strokes, what Pascal does in nine ({ and } as opposed to begin and end;) This one's a personal preference issue. Personally I find begin and end 100 times more readable, but I also understand that others may prefer their curly braces.
- In my post about garbage collection, some of the commentators reminded me that if you use Delphi, because it doesn't have garbage collection, you have to write 40% more code (all those silly try..finally clauses). Again, you may have valid reasons to want garbage collection, and I respect those reasons. But don;t tell me writing less code is a good reason.
- The push towards functional programming is another one. I'm told that using a functional programming language for certain problems would result in me writing a lot less code. Look Ma, I wrote all that code in one line! I may be a bit harsh here, as some of the functional constructs are really elegant, but what I'm getting at is that use something by all means if it results in your code being more readable, and not because it results in a few less lines.
- Pascal requires an interface and an implementation section. You declare a class twice. It must be bad right? Like I've said before, for me, a Pascal class is immediately readable. The interface has no clutter. To achieve the same thing with say, a C# class you need code folding.
I could go on and on. I think the theory goes that if you can type, say 70 wpm, and that you can't physically type faster than that, then the only way to churn applications out faster is to use languages and constructs that need less typing. The theory implies that if you are writing 40% less code than I am, (and we both type at the same speed), then you're producing 40% more work than I am. What the theory conveniently ignores is that I may think 40% faster than you. I'm not saying that writing less code is a bad thing. I will always write less code if I can, but never at the expense of clarity. I will add begin and end where the compiler doesn't need them if I think it makes the code less ambiguous. I'll not use the with construct , and retype the object or record instance each and every time, if I think the code is more readable for it (it always is). The important thing to remember is the speed a developer can write good maintainable code is rarely due to the number of characters he/she can churn out. A lot of it is to do with the thought that goes into producing the code, when the hands are no where near the keyboard. It's to do with the cost of maintenance of that code. This all reminds me of those C competitions where C enthusiasts would vie to write the shortest piece of code that actually does something. It doesn't matter that you had to sit down with pen and paper for a few hours to figure out what his little program did. Aim for clarity and eliminate ambiguity. If that means you end up writing a bit more code, so be it, in the long run you'll actually save time.
Posts
