Jeff Atwood has a great post on this. Its esentially about the tendency of code to get larger and larger, ad infinitum. I agree. Code can become so large that its unwiely and difficult to work with. A case in point.
I’m writing a product management system, on and off as a hobby to fill in the hours. Until a few months ago, my data strucures and my data source code were in the same class. This gave me a problem.The data sorce code was problematic meaning that it brough everything else down with it. I seperated the two ( logically) seperate enities and you wouldn’t belive how much better both class now are both to work with and to trouble shoot. So a little foward planning would have made me code smaller and better.
Which brings me to Scott Hanselman’s post on this.
I think that pre-planning is part of it, but there’s only so much Big Design Up Front (BDUF) you can do. More and more, as I work on larger and larger projects (and product suites) I realize that refactoring effectively and often is as or more valuable as pre-planning.
So, simply resisting the tendancy to add sub routines, modules, classes, etc to fill the immidate need for functionality (or i my case, data) is not enough. Some sort of planning is needed, formally or not. Having a good idea of what a given sction of code needs and does not need is of paramount importance. I add the “does not need” since I often find subroutines that have long since been made obselete by a newer subroutine or requirement. It may be 5 or fifty lines of code, but unused subroutines waste time, space and can lead to confusion when reading the code ( Code is part of the documention).
Scott seems to have the same problem:
I ran this CQL query without the “TOP 10” qualifier on some code on one project and found 292 methods that weren’t being used.
292 methods? Unused? It’ll make me feel better next time I read my code.
And it serves to highlight the point. If its not needed, get rid of it!
Random Musings 