ARCHIVE: TIPS & TRICKS
Response to: Working with someone else's code
Stuart Mccormack
06.27.2000
Rating: -4.29- (out of 5)
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.
|
|
|
|
|
|
