Fog Creek Software
Discussion Board

Code Cleanup

I'm looking at a relatively modest-sized codebase, and I'm responsible for accomplishing a couple of basic things. 

first of all, i need to remove old and unused (unreferenced) functions.  i use tools from a company called CAST to analyze the codebase, and it's gives a pretty accurate assessment of some of the unused parts of the codebase.  however, the actual removal still requires manual verification and removal... any similar experiences someone can recount to give me an idea how this is done in different companies?

The ultimate goal of this project is to increase code-reuse. my boss basically wants to first clean up old code, then use the CAST tools to we can then figure out where a lot of duplicate functions are and improve reusability.  can reusability really be introduced like this? 

i am new here, and am pleased to see that they are taking efforts to improve software practices... however, i personally i feel that reusability requires ground-up thinking, and has to be incorporated into a fundamental design?  how do i introduce reusability ex post facto? 

any comments?

Tuesday, November 19, 2002

Are you aware of refactoring?

Too bad they're not having their original programmers refactor the code, it's a good learning experience.

Tuesday, November 19, 2002

Run, don't walk, to buy a copy of this book:

Refactoring is what you're doing - improving the design of your existing code. And the book is a really good read.

The most important thing to have when refactoring is confidence that you haven't broken anything. The only way to get that is a set of automated tests. Unfortunately you don't have one built in probably, so you'll have to build it in as you go. Write a test case before you make a change. Run it. Make your (small) change. Rerun. Did the test break? Then you know you did something wrong, so back out the change. Add more test cases, make more changes, lather, rinse repeat.

It's hard to get started at first, but once you get rolling it'll work out really well.

Chris Tavares
Tuesday, November 19, 2002

I agree with Tj and Chris - using refactoring techniques is the best/easiest was to proceed. Martin Fowler's book is excellent for learning how to do this - the last half of the book contains 'refactoring patterns' (like design patterns, but for refactoring).

You're lucky if your boss actually recognizes the need and usefulness of code cleanup. At my last employer, I only had a single instance of being able to do this (and that was only because it was the only way I could see to add new functionality in the given time). I actually took out 1/2 the lines of code even with the increased functionality.

Tuesday, November 19, 2002

Joel's written a bit about refactoring, and I've found his comments helpful...

Yes, you can do this kind of cleanup in-place.  I've done it, and it's very gratifying (if a little scary) to realize that you've deleted huge swaths of code and replaced them.  The key thing to remember (aside from keeping a backup, naturally) is only to change one thing at a time.  That way, if you have to back out of a change, you can do so gracefully and with a minimal loss of effort.

Tuesday, November 19, 2002

Also, some IDE's are refactoring browsers, and can automate a lot of the effort. For example, I've been using Eclipse ( ) for a couple of months, and can refactor Java code much faster than before.

Wednesday, November 20, 2002

I would do the following...

1) keep a copy of the latest labelled working codebase (use sourcecode control) at all times

2) remove all dead variables and procedures (nuke em!)

3) rescope overscoped variables

4) start looking for reuse options, this will usually involve 'tweaking' routines that do similar things, and using referenced parameters etc. This is where the fun begins.
You may find it easier to comment out duplicate functions while you tweak the master one, and only nuke the commented stuff once you've finished.

5) At this stage you should understand the codebase fairly well and re-architecture options should start to emerge.

I favour doing the small stuff first and using the experience to increase my understanding along the way, as long as you don't break anything every change you make is an improvement.

Some people like to work the other way, Fowlers book is a bit of a bible, unfortunalely I lent my copy to somebody who never gave it back..

Wednesday, November 20, 2002

You can take a look at "Understand for C++/Java/Ada/FORTRAN " from

I just happened to use "Understand for C++" in my own project and it helped me extremely well.

"Our tools parse Ada 83, Ada 95, FORTRAN 77, FORTRAN 90, FORTRAN 95, K&R C, ANSI C and C++, and Java source code to reverse engineer, automatically document, calculate code metrics, and help you understand, navigate and maintain source code that has grown too large for one person (or even a group) to know"

Evgeny Goldin
Wednesday, November 20, 2002

Refactoring and reuse are not the same thing. I think the other posters are right and that refactoring is the first step.  The original poster is also correct in that reusability is an architectural design constraint that is devilishly hard to retrofit. It affects module/class design, data-flow and dependency management as well as the nitty-gritty of factoring out common stuff.

Jeff Kotula
Wednesday, November 20, 2002

With respect to refactoring Fortran programs, may I suggest that you view

Ronald C. Wackwitz
Thursday, July 8, 2004

*  Recent Topics

*  Fog Creek Home