Problem solve Get help with specific problems with your technologies, process and projects.

Response to: Working with someone else's code

This is a response to the previous tip, "Working with someone else's code."

Response to: Working with someone else's code:

Reader Stuart McCormack responded to the tip we published on June 20, 2000 about the problems of working with someone else's code, and ways to reduce the problems to manageable proportions. Herein Mr. McCormack weighs in on additional precautions any programmer should take to make sure that his code can be upgraded and enhanced, not tossed once he has left for some other pastures.

_____________________________________________________________
The only thing that can be said for maintenance programming is that, unless you're a complete blockhead, it teaches you how *not* to write code. Mr. Smiley's article is good advice and it reminds me of another valuable practice that very few of us follow. Like the basic points of Mr. Smiley's article, this discipline is, I believe, valuable to all programmers, not just VBites.

After you've designed a particularly tricky algorithm, coded it up, nursed it through debug and finally got it working to your satisfaction, DON'T MOVE STRAIGHT ON TO THE NEXT TASK.

Sit back and take a good look at what you've written, particularly the flow of control. Ask yourself the following questions.

1) How far has the implementation diverged from your original plan?

If it's gone quite a ways, you can almost certainly (quickly) redesign the logic to make your code more logical (this is NOT an oxymoron). Take those kludges OUT.

2) Do the variables you designed, named and used still all make sense?

Often their meanings no longer quite match their names. Also, you may have some there that aren't doing anything, or have two masquerading as the same thing. Did you really need to make that thing global (Public) or should you have passed it as a parameter?

3) Would any part of your code make more sense as a SubProgram?

Is that code segment a bit too detailed for what you're doing here? Could you reuse it elsewhere? Are you using it a number of times (in a subtly different guise) here? If any of these questions return True, you should bundle that bit up as a Sub or Function and get it out of there.

4) Is it efficient?

Could you do this FASTER? Programmers have been telling me for 25 years that efficiency is no longer important. That spending a bit more effort to save a few bytes or cycles is a waste of time. Strangely though, the hardware guys keep designing faster computers. I wonder why?

I believe that if you're not doing it efficiently, you're probably not doing it RIGHT. (NEVER sacrifice accuracy for speed though.) Thinking how you could do things faster is often a very good insight in how to do things better. Think about it.

5) Is it too complicated?

Can it be expressed more clearly? Here's a good rule of thumb: If it's got 10 IFs in it, it's too complex.

6) Can you read it?

Is your code legible, clear, and concise? What chance will the next Wally have of understanding what you just sweated blood for?

Programmers are a weird bunch. Ask them to document something and they'll put it off and put it off. They'll complain that it's 'Not their job'. Give the same mob an un- or poorly-documented product to use (say an OCX) and they'll tell you that it's a useless, unprofessional pile of junk. What's more, they'd be right.

A "BAD" programmer is one who's work ends up in the dustbin before it should. The best way to do this is to not document your code. You can be brighter than Einstein but, if you refuse to give your code the documentation it deserves, you're a waste of oxygen. Go design web pages.


Having asked yourself these questions and looked critically at your code, GO FIX IT. At most this process will cost you an extra half an hour. What you'll get out of that time is a product that's more robust, more maintainable, longer lived and, maybe, more efficient.

***********************************************************************
Read John Smiley's original searchVB.com Tip and Trick from June 20, 2000 at http://searchVB.techtarget.com/tip/0,,sid8_gci207308,00.html> Written by John Smiley, MCP, MCSD and MCT, is an adjunct professor of Computer Science at Penn State University in Abington, Philadelphia University, and Holy Family College, and has been teaching computer programming for nearly 20 years. He also teaches a number of very popular online courses at SmartPlanet and ElementK. In addition, John is the author of four very popular Visual Basic books, and is reportedly the first guest to write a computer program live on ZDTV's Screen Saver's show.

John Smiley is president of Smiley and Associates http://www.johnsmiley.com/smass/smass.htm, a computer consulting firm located in New Jersey.

Dig Deeper on .NET job advice

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCloudComputing

SearchSoftwareQuality

TheServerSide.com

Close