Al Pascual



Geo RSS
Geo Twitter Timeline

Blogs I read

<January 2009>
SunMonTueWedThuFriSat
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

Keeping the code clean and tidy

This week I have been so busy with the ESRI user conference, I spend evening watching the podcasts. Tomorrow morning I need to wake up around 4 to go down to San Diego and work at the UC. Its going to be my first ESRI User Conference. As well as being a busy week because the UC, I have been finishing and cleaning up a project, and raises the question about how do you clean up code?

When you find a few lines that you do not need anymore, but they work, do you comment out the code or you delete it? Now think about it very carefully. You got QA or requirements telling you don't need that functionality anymore. However you know that you spend sometime working on that piece and you may need it somewhere else or worse, somebody is going to change their minds. Would you comment out the code? Delete the code? Or add the code in a special place to use someday?

Another question, do you enable the warning to let you know what public methods don't have comments? Do you make sure to comment all the classes and public methods?

What code analysis software do you use? Do you use Visual Studio 2005 Team Foundation Server?

Do you test your classes? What testing procedure do you use?

I'm not as good as I would like to be testing my classes or cleaning up, when you have so many lines of code in different assemblies and project, gets a little harder to do the clean up. I wonder, what process do you use?

Cheers

Al

Comments

SamuraiNixon said:

For the most part GET RID OF CODE THAT IS NOT USED! It needs emphasis. The more "stale" code you leave in (especially when you have many workers on the same code) the more you will have other developers using "old" code. The lava-flow antipattern (http://www.antipatterns.com/lavaflow.htm) is one of the biggest annoyances with working with established code. Sometimes you will see several different ways of coding the same thing (obviously this should be refactored) and sometimes some the code is not used. What happens many times with unused code (especially in projects that have 100,000 lines plus) is that it gets forgotten and if you need to make some large change you end up wasting time on code that is not used. In the long run having tight (anal) code saves your clients money and time (of if it is your own business then it makes no sense to have sloppy code). Public methods should always have comments.
# June 21, 2007 1:37 PM