Any file management strategy?

[Author #1]

I think this may be a common problem for many developers here. That
is, quite some files ended up not being used by our application, is
there any software that can help us find out what files are not used
so that we can choose to erase them from the project? I also created
a lot of stored procedures in my SQL Server 2005 database, also quite
many of them ended up not being used at all.

Any idea or pointer is highly appreciated. Thanks.

 

[Gregory A. Beamer]

I think this may be a common problem for many developers here. That
is, quite some files ended up not being used by our application, is
there any software that can help us find out what files are not used
so that we can choose to erase them from the project? I also created
a lot of stored procedures in my SQL Server 2005 database, also quite
many of them ended up not being used at all.

Any idea or pointer is highly appreciated. Thanks.

For code, you can use tools like ReSharper to find dead routines.

As for the database, try Apex SQL Clean or RedGate's SQL Refactor.

In the future, covering your code with tests and deleting tests that no
longer apply can help you identify dead code. Simply run the tests under
coverage and find the spots that are not covered. If you have done
things properly, you can safely delete all of the routines that are red.
This type of discipline can be done for free, as you can download open
source for both tests and coverage (like nUnit and NCover).

 

[Author #1]

For code, you can use tools like ReSharper to find dead routines.

As for the database, try Apex SQL Clean or RedGate's SQL Refactor.

In the future, covering your code with tests and deleting tests that no
longer apply can help you identify dead code. Simply run the tests under
coverage and find the spots that are not covered. If you have done
things properly, you can safely delete all of the routines that are red.
This type of discipline can be done for free, as you can download open
source for both tests and coverage (like nUnit and NCover).

Thank you so much. I took a look at NCover at http://ncover.sourceforge.net/why.html
, where it says:

<quote>
Code coverage can help by identifying:

* Areas of code that need additional testing.
* Dead code (code that doesn't do anything either because it
should be deleted or due to a bug).
* Dead files not included in solutions but still in CVS.
</quote>

Looks it is exactly what I need. Let me give it a shot. Thanks again.
I hope it'll clean my project files.

 

[Gregory A. Beamer]

Thank you so much. I took a look at NCover at
http://ncover.sourceforge.net/why.html , where it says:

<quote>
Code coverage can help by identifying:

* Areas of code that need additional testing.
* Dead code (code that doesn't do anything either because it
should be deleted or due to a bug).
* Dead files not included in solutions but still in CVS.
</quote>

Looks it is exactly what I need. Let me give it a shot. Thanks again.
I hope it'll clean my project files.

NCover will not automagically do the work for you. You will have to
either run all of the routines in the executables/libraries, or you will
have to set up unit tests to run them.

If you use NCover and miss a routine, you will get it marked as dead
code despite it still being in use.

What I am saying is be sensible and make sure you are truly "covering"
all of the use cases for the application prior to whacking code. If you
are doing this without automated tests, comment out code first and make
sure it gets through user acceptance before deleting. Or, better yet,
use a source code repository so you can roll back. Or, better yet, both,
as commenting can make it simpler in case you find the code is no longer
dead after another check in.

Another thing I would have you look into is Continuous Integration. You
will have to use Source Control to take full advantage, but CI products
will compile your entire source base and can be set up to run automated
tests and coverage as part of the process. You can use open source like
CVS or SVN (a bit easier in my opinion) for source control and still
hook CI products like Cruise Control .NET into the process.

Peace and Grace,

 

[Author #1]

NCover will not automagically do the work for you. You will have to
either run all of the routines in the executables/libraries, or you will
have to set up unit tests to run them.

If you use NCover and miss a routine, you will get it marked as dead
code despite it still being in use.

What I am saying is be sensible and make sure you are truly "covering"
all of the use cases for the application prior to whacking code. If you
are doing this without automated tests, comment out code first and make
sure it gets through user acceptance before deleting. Or, better yet,
use a source code repository so you can roll back. Or, better yet, both,
as commenting can make it simpler in case you find the code is no longer
dead after another check in.

Another thing I would have you look into is Continuous Integration. You
will have to use Source Control to take full advantage, but CI products
will compile your entire source base and can be set up to run automated
tests and coverage as part of the process. You can use open source like
CVS or SVN (a bit easier in my opinion) for source control and still
hook CI products like Cruise Control .NET into the process.

Peace and Grace,

Ah? I didn't think that it would so complicated. Given what you say,
it seems like it'll be easier if I manually inspect and remove unused
files.

 

[Gregory A. Beamer]

Ah? I didn't think that it would so complicated. Given what you say,
it seems like it'll be easier if I manually inspect and remove unused
files.

Or, for app code, consider downloading the trials of Apex SQL Clean (or Red
Gate's tool) and Resharper and use them to clean. I do warn you that if you
play with ReSharper enough, you will likely wan to buy it. ;-)