Wednesday, September 10, 2008 #

Thoughts on programming language and maintainability

Recently, I have been working on maintaining two “legacy” systems. One is in VB6, implemented by a person who was not a programmer, but only trained a few weeks for VB6. The code quality is extremely poor. There are even no indentations in the code, and all variables are not properly named, for example, if there are 5 text boxes on a form, they will be just named as Text1(0), Text1(1)…Text(4).  So, I guess I don’t have to say too much and you get a picture of what it looks like. Another system is done with .NET 1.1 using C#, and it is written primarily by a guy who, is considered as a coding hero or maybe, more precisely, a coding cowboy. I didn’t work with any VB stuff before this one, and I have been using C# for 4-5 years.

So, how easy I found maintaining these two systems? This probably will surprise you, but I do find maintaining the VB system is much easier.

Why I find maintaining the VB system is easier? Let me tell you what I normally do to fix a bug. Normally, I will start from finding the form. All the form files are inside one folder, and thank god, they are named properly. So it is not a big deal to find it. And then I will find the control, normally a button which triggers off the function which has a problem. I will then double click on the button, and it will take me to the event handler in the code view. There are normally at least a few hundred lines of spaghetti code. I do sometimes find it is a bit frustrating to work on some code like this, but I will tell myself to be patient, and normally it won’t take too long to locate the line has problem, and fix it normally not a big problem, and I won’t have to worry about fix this one will cause another ten bugs elsewhere because there is no code sharing at all.

While, fixing a bug in the .NET system is completely a different story. Normally finding a file is a big challenge. There are more than 50 projects in the solution (not because the system is large, it could be just 5 – 10), a project may contain only one file, but there are 10000 lines code in it and dozens of class definitions. There are interfaces which you will never find what class implemented it, and there are stuff may be loaded into system via reflection on runtime. There might be some super complicated and wired inheritance structure. Sometimes I get impression, that it is designed not to be found.  I don’t want list of the problems here, I guess everyone has worked on this kind of system knows what I am talking about.

The point I want to raise here is, in term of maintainability, maintaining a well implemented object-oriented system might be easier than a well designed procedural system, but maintaining an object-oriented crap is even more difficult than doing a procedural crap. Also, no architecture is generally better than over-architecture. I think there are some reasons:

  • An object-oriented language itself is more complicated than a procedural language. The cool features like inheritance and polymorphism are all adding complicity and indirection into the program. Note, complicity and indirection are very bad thing, so if they don’t buy you anything, they should not be there.
  • A procedural language might not express well (spaghetti code), but it doesn’t lie, but an object-oriented language does. It could deceive you by using cool stuff like inheritance, reflection, delegate, extension methods, etc.

So, don’t take it for granted that an object-oriented language will automatically make your system more maintainable. What does make an object-oriented language work is the “loose coupling, high cohesion”, is single responsibility principle, is the open-close principle. It is not the cool language features or cool design patterns.

    

Posted On Wednesday, September 10, 2008 7:25 AM | Comments (4)

Copyright © Changhong Fu

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski