Over the past year I have done a fair bit of maintenance on a legacy app. One thing that struck me is that the app has had a number of developers over the years. Each developer has stamped his/her mark on it. In some cases the stamp is great and in other cases what they have done is rather average. I also noticed a distinct lack of consistency in variable/class names, documentation etc. My job has been to fix a few defects or add some functionality. Typically taking days to understand how the code works and then making 5-10 lines of changes. In each case I have been tempted to redo, rewrite or refactor the code into my style. (I suspect most developers are often tempted with these dark thoughts). But then I faced the risk of breaking something or stamping yet another developers fancy onto the every-growing mangled mess of code. (A side issue is that I see coding as a form of art - maybe a later blog).
Recently I saw this oldish book at work The Elements of Java Style. Nothing too earth shattering in the book but I just loved these principles:
- Adhere to the style of the original
- Adhere to the Principle of Least Astonishment - avoid doing things that will surprise the user of your code (If I had a dollar for every time I have been astounded by someone's "creativity" ...)
- Document any deviations
"All good software performs well. But great software, written with style, is predictable, robust, maintainable, supportable, and extensible."
There are plenty of style guides out there. But in my experience developers just don't do it. Just imagine if we did. Wouldn't it be cool?
No comments:
Post a Comment