Memi writes about a simple case in which VB.Net's “wordiness” adds to the clarity of the code.:

 

“Inherits vs Implemets in C# 

  I guess the difference is obvious - you inherit a class and implement an interface.

If you write in VB.NET, the difference just shines.

...However, as you sure know, in C# things are a bit messier“

 

I totally agree. One of the things VB.Net (and VB before it) was trying to solve is the code readability issue. This is something I have total respect for. As systems grow in complexity and the technology and programming languages grow to higher and higher levels, the act of coding has become (or at least is in the direction of) more about achieving a task and less about struggling with code. The tools are becoming available to take more and more off our hands of the trivial and mundane stuff using code generation techniques, pre-built tools and code and visual wizards and gadgets. Added to that is the growing realization that readable, maintainable code is better than less readable and maintainable code. C# “inherits“ from a language that was not about readablity. VB.Net is based on exactly such a concept -  a concept which at times can lead to some hourrendously long and scary bits of code even though you are using a language designed to promote just the opposite. But I digress.

I love the fact that in VB.Net the langauge forces your code to announce exactly what it is doing, and even what it is not doing. “I am implementing and interface. I am inheriting  a class. I am not overridable. You must inherit me.“ and so on. To me this is brilliant in a way. Developers are lazy bastards. The last barrier between a lazy bastard and readable code is the compiler. VB.Net took that concept seriously and ran with it.

 

One of the ways to make things more readable in non C/C++ has always been naming conventions. Big, important and solid naming conventions helped the poor developer save themselves from maintenance hell (to a degree). There are actually conding contests on the internet that defy the C programmer to come up with the most distorted code that compiles. Yes. People have been drawing with code. Amazing.

With the advant of higher level languages and IDEs, people have started slipping up with doing proper naming conventions. The main reasons for that are of course - the tools. The IDE provides the developer with loads of information about the code the developer is currently looking at. I can just hover my mouse on a variable and see exactly what type it is, not having to name it with a specific prefix or any sort of notation. I can jump between procedures to see the code inside them, not having to write really meaningful names for those procedures. I can be a lazy bastard if I wanted to and the fancy IDE that I use will just silently help me along reading my own horrible code. But that's just me. Someone else that needs to read my code will find it much harder to understand the code I wrote, even with all the fancy help features. It's way to harder to read and understand the meaning behind the code you didn't write when all that time you are struggling to move your mouse over to a particular word to see what type the variable is, or jump to a prcedure to see what's inside. It's keeping you from understanding the driving logic behind the code. It's like looking at a big picture, only able to see one specific color in that picture at any single moment.

SO, the dissonance between the ease with which I can produce ugly code and the lack of ease in maintaining that code later can almost be described as inversly proportional to each other.

It's the perfect technology equasion: technology advancement is inversly proportional to the minimaly required mental abilities of the people who will use it. McDonald's cash registers is the perfect example. These people have pictures they need to tap on to do an order. Nothing more. Will we see the same here?

this trend was very appearent when VB first came out. Suddenly everyone and their mother could do a simple program. Sure, no one could understand the code, but it was just to easy to set aside. Now these features have matured even in the RAD world, and that's exactly the kind of conversation that is growing in today's blogsphere and other places: redability is about communication. Communication, agile methodologies, test driven development -all those things are based on the same principals. But I digress again :)

 

What's the best way to tell how readable your code is? try reading it in Notepad. No syntax highlighting, no tooltips. nothing. Scary, isn't it? Naming conventions were invented because people were doing the equivalent of just that for a lot of time. do we really need to worry about such situations anymore? I know I have almost always read code on the screen rather than print it, but I do know people who do code reviews with printed books of code. 

 

What's the point I'm trying to make here? Readable code should not be about the tools you write with. It should be one of the most fundumental things every developer should learn. It helps you organize your thoughts and ideas, it saves you from writing comments that become irrelevant 5 minutes later and it lets you be proud of your code.

 

Memi adds the following:

“I was in a number of presentations where the presenter showed a code silimar to the above, and said the class inherits from IInterface. But the highlight of this was in the (great) TechEd in Israel, when a presenter said, when talking about a code similar to the above, that we have here a multiple inheritance.“

 

yikes! is all I can say about that. Sure, techinically he may be correct, the class does both interface inheritance and implementation inheritance (both totally legitimate technical terms which describe both cases), but still, the “multiple inheritance“ term is a bit too overloaded as is.

 

BTW: where were you Memi? I was loking for you!