Avoiding IT Errors with a .NET Slant
- Desk Check/Reread the Code After It Has Cooled
- Have Another Analyst Read Your Code
- Mark Test Code Flamboyantly
- Look for Productivity Aids
- Limit Copy-and-Paste Operations
- Dispose of Unmanaged Resources
- Make Your Error Routines Return Data
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Do any of the following real-life examples feel vaguely uncomfortable because they’re too familiar?
- A copy-and-paste operation in which key variables don’t get changed to reflect their new use. (Even more embarrassing when copy-and-paste code is found while working on another fix!)
- Production code implemented with a test code still active.
- "Fried Brain Syndrome" that hits after hours of fatiguing work on repetitive tasks. (Major damage can be done by an otherwise competent person who was overloaded and tired.)
- Nonfunctional error routines.
In this article, we’ll explore some of the main culprits that I’ve encountered in my programming career, which dates from COBOL punch cards to Microsoft’s Visual Studio. After detailing the source of each error, I’ll explain some solutions that have helped me.
This article is geared to the population segment that’s not involved in "full lifecycle development" with source-controlled versioned releases, code walkthroughs, unit testing, a QA department, and of course technical writers to do documentation. (By my unofficial survey, this limits the audience only slightly in the real world of "You need it when?")
Following are some of the concepts that help me to decrease my error flow. (Nothing can remove the human element totally.) Most concepts are common sense, but tend to get overlooked in production deadlines.
Desk Check/Reread the Code After It Has Cooled
Programmers get into a "creative zone" when writing code. This zone has a kind of euphoria in which everything feels connected and logic flows—or at least it seems to flow, whether or not it does. It’s good practice to review a paper copy (so you can read it offline) later at home that night. Even better, read it the next day, when distance has had time to settle in and you’re able to give the code a fresh look.
One of my worst habits has been to put the code into production immediately after a debug session but before reviewing it again, somehow trusting my warm fuzzy feeling about the logic. I’ve learned that what I think sometimes doesn’t get translated to code, and some assumptions are no longer warranted in the light of the next day.