Has this ever happened to you? You're sitting at your computer, mired deep in code, trying to understand what is going on, and trying to figure how to approach your changes.. and all of a sudden it strikes you -- you're looking at a piece of code and you're not even sure it's being used any place!
I have to admit that I've literally lost days of work dodging and working around problems caused by code that, well, simply wasn't being used any place. I don't think I'm alone.
When we look at code in a code base, the default assumption is that it is being used someplace. If it isn't, it's a subtle lie. It's something that could trip us up.
I think that, fundamentally, there are two different modes of software development. In one mode, we write libraries and frameworks. When we write libraries and frameworks, we don't know how much of our code is being used by our end-users so we have to assume it's all used. In the other mode, we write applications. When we write applications the only code we have to write is the code that we are going to use.
Application code has to be kept honest and the way to do that is to ruthlessly delete things that aren't being used. It's less work in the long run, and it's nice to know, when you look at a piece of code, that it is there for a reason and that you aren't wasting your time.
It's worse when there are even unit tests for the bit that nothing is using. You're thinking to yourself, "Surely, no one would bother writing tests for this unless something was using it..."
I don't know how many people have heard of it, but Ivan Moore has this cool tool called Jester. It takes your code and goes through it, one file at a time, introducing little errors, and then running your tests after each introduction. If it can muck with you code and all your tests still pass, there's a problem with your coverage so it alerts you.
The process is time-consuming, but the cool thing is that it finds more than dead code. It also finds ghost code, code that's still animated (it executes) but can't affect the material world (changing it doesn't produce a functional effect).
That is still better than trying to figure how can a piece of code is working at all. I have stared at code that is not supposed to work, but somehow never fixed.
I'm lost here, a piece of code that isn't being used anywhere? I don't know about others but I use an iterative approach. Each application has its defined Spec. (Implicit or actually scratched out by your BA). Now from that point following things iteratively would ensure that you build on your app. via your code until all requirements are met.
Unless you mean a certain functionality at the application level that is not being used, then I'm sure tons of us have come across it.
Kondwani Mkandawire wrote: > I'm lost here, a piece of code that isn't being used > anywhere? > I don't know about others but I use an iterative > approach. > Each application has its defined Spec. (Implicit or > actually > scratched out by your BA). Now from that point following > things iteratively would ensure that you build on your > app. via your code until all requirements are met.
In an ideal world, I agree... But for a real-world example, the code-base I'm working with now is about 15 years old, and consists of about 5 or 6 million lines of C and C++ code.
I'm sure that possibly as much as 5% of our code isn't being used, but there's no easy way (that I know of) to identify that code.
Code coverage tools and release requirements (eg. code coverage is 70% after all test suites are run) can help with this. Especially when you consider that there all all kinds of code coverage metrics to choose from. So, even though 70% doesn't sound like a lot (it actually is), you can also require 100% coverage on modules, functions or whatever.
This isn't only a problem in software, either. I started out as an EE and in my first job I remember trying to figure out a particular circuit for a whole day. When it became clear to me that the thing was really not connected to anything else on the board (besides ground), I went to the person who had designed the thing and asked him about it. He explained that he just put it there because one of the old senior engineers said it should be there.
> > In an ideal world, I agree... But for a real-world > example, the code-base I'm working with now is about 15 > years old, and consists of about 5 or 6 million lines of C > and C++ code.
15 years is quite a while back, I'm no Software Engineering History expert but I'm sure design practices since then have changed considerably. In any case could the fact that some of the code is not being used have something to do with the fact that the Spec has changed considerably. From the OP I got the impression that he was talking of building an application from scratch and not recycling code. In my opinion if a Spec. is any decent, and if requirements are properly sketched, I don't see why a developer or team of developers would include Code that will never be used. Unless they're on a tea break, and decide to include their own fictional requirement in the Spec. > > I'm sure that possibly as much as 5% of our code isn't > being used, but there's no easy way (that I know of) to > identify that code.
The Call Hierarchy tool in Eclipse is a fantastic way of discovering uncalled code in a Java codebase. I wish I had that sort of tool available to me in all my work.
> In any case could the fact that > some of > the code is not being used have something to do with the > fact that the Spec has changed considerably.
Spec? Most of the older code here never had a Spec in the first place - but if it did, it would certainly have changed...
> From the OP > I got the impression that he was talking of building an > application from scratch and not recycling code. In my > opinion if a Spec. is any decent, and if requirements are > properly sketched, I don't see why a developer or team > of developers would include Code that will never be used.
True - but again, in the real world, most specs and requirements have some degree of vagueness to them.
I think that even with a pretty decent spec and set of requirements, it isn't unlikely that a dev will be writing a class and think that they'll need a method "foo", and then either the method isn't needed, or the code that used "foo" gets cut from the release 'cause they are behind schedule...
thank your for your thoughts about "lying code", I´d call it "unused Code", but ok.
The question for me is: How could we improve the process of finding unused Codes? Do you think we can make it esier to detect with the right Design? Or do you think we should evalutate technical solutions like a code coverage-tool?
I´d love tool that suggests parts of code to throw out after running the tests. If the Application doesn´t run after throwing out that code, we could undo the step with the version-control and add a test to keep it coveraged or decide to refactor the application so that this part of code can completely be throughn out.
> Dear Michael Feathers, > > thank your for your thoughts about "lying code", I´d call > it "unused Code", but ok. > > The question for me is: How could we improve the process > of finding unused Codes? Do you think we can make it esier > to detect with the right Design? Or do you think we should > evalutate technical solutions like a code coverage-tool? > > I´d love tool that suggests parts of code to throw out > after running the tests.
Jens, thanks for the note. There is a tool like that, it's called Guantanamo:
I haven't had a chance to use it, but it seems pretty extreme.
I think good design helps find dead code, but still.. it's great to have technical tools. Often when I work with teams, it's powerful just to question whether something is used. With a little grep-ing, often you can tell.
Previous Topic
