December 18, 2010

Remember, Fortran is not object oriented

I spend most of my time programming, making bigger and bigger pieces of software. I am in the same thread since 1983, when I learned Fortran during the summer break, and one thing that happens is that every time I review some code from a few years ago, I think ‘how in the world was I thinking this was a good idea?’.

My last pet peeve is about properties. They are part of C# (and Delphi before that), they are shown in every example, and I learned to use them everywhere. You create your class, fill it with properties, and off you go. If you are fancy, now you show them in a grid and congratulate yourself for not being using tables.

Well, you are on the same  old train. It is not a table, but you are still editing values in a row, calling it an object. Doing that in Fortran surely will be messy, but the end result will be no more unmaintainable than C#, and in a few years the only solution for anyone sane will be to rewrite, or torture a junior developer adding still more properties and keeping them in sync in forty disconnected places.

The problem is, now you need to know what is the meaning of the values in that property. Say you have one of those ‘InProcess’ rats in there. True means something is happening and the object should be left alone, false and you are free to do something else. But a few months later you find there are two different kinds of ‘InProcess’ status, and you can do Foo in one, an Bar on the other. Then you change the boolean with an integer, refactor the 80 lines that were using InProcess directly, fix the unit tests, if you have them, and declare the bug closed.

Wrong, the bug is still there, and now you have a few new guys doing different things based on that status, and changing it, and the junior dev will add a third value (hey, it is just an int, and the pattern to copy is there!), and two years later nobody know how that works, and a senior dev has to trace what the hell is going on, and make a document with a web of disconnected numbers, connected with lines. Great, time to rewrite! We will do it after we add this new value to the property ‘IsDeleted’, because now we want to delete things but keep them visible for the accountants :)

I was reading my own code from the last ten years and just hate it and want to burn it all, except that it is still producing money, and my goal for the next few months is to keep the number of properties in my classes to the minimum. Think three times before putting that innocent setter in there. Do I really need to change a value? An isolated value in a class, disregarding the context? If the context is not important, why is the property in the class then? OK, if the context add value, why the need to change an isolated property, forcing the next guy ‘to know’ what he is doing?

Can you express the idea better with a method? Are you sure it is more work to do that? Is it more work in the five minutes you need to write the method, disregarding the hours wasted later trying to know why the whole program is going bananas in a situation that happens only once every thousand calls? Funny thing now is that everything seems to get called a million times a day, but still finding a bug in a thousand is difficult, and you waste some hours, and your day is more miserable, and life would be better just rewriting all the code.