c# ean 13 barcode generator An Ineffective Approach in Visual C#.NET

Printer EAN13 in Visual C#.NET An Ineffective Approach

Unfortunately, programming classes in colleges and universities hardly ever offer instruction in debugging. If you studied programming in college, you might have had a lecture devoted to debugging. Although my computer-science education was excellent, the extent of the debugging advice I received was to put print statements in the program to find the defect. This is not adequate. If other programmers educational experiences are like mine, a great many programmers are being forced to reinvent debugging concepts on their own. What a waste!

Programmers do not always use available data to constrain their reasoning. They carry out minor and irrational repairs, and they often don t undo the incorrect repairs. Iris Vessey

In Dante s vision of hell, the lowest circle is reserved for Satan himself. In modern times, Old Scratch has agreed to share the lowest circle with programmers who don t learn to debug effectively. He tortures programmers by making them use this common debugging approach:

Find the defect by guessing To find the defect, scatter print statements randomly throughout a program. Examine the output to see where the defect is. If you can t find the defect with print statements, try changing things in the program until something seems to work. Don t back up the original version of the program, and don t keep a record of the changes you ve made. Programming is more exciting when you re not quite sure what the program is doing. Stock up on Jolt cola and Twinkies because you re in for a long night in front of the terminal.

Don t waste time trying to understand the problem It s likely that the problem is trivial, and you don t need to understand it completely to fix it. Simply finding it is enough. Fix the error with the most obvious fix It s usually good just to fix the specific problem you see, rather than wasting a lot of time making some big, ambitious correction that s going to affect the whole program. This is a perfect example:

Who needs to dig all the way into Compute() for an obscure problem with the value of 17 when you can just write a special case for it in the obvious place This approach is infinitely extendable. If we later find that Compute() returns the wrong value when y=18, we just extend our fix:

x = Compute( y ) if ( y = 17 ) x = $25.15 else if ( y = 18 ) x = $27.85 -- Compute() doesn't work for y = 18, so fix it -- Compute() doesn't work for y = 17, so fix it

Satan has leased part of hell to programmers who debug by superstition. Every group has one programmer who has endless problems with demon machines, mysterious compiler defects, hidden language defects that appear when the moon is full, bad data, losing important changes, a vindictive, possessed editor that saves programs incorrectly you name it. This is programming by superstition. If you have a problem with a program you ve written, it s your fault. It s not the computer s fault, and it s not the compiler s fault. The program doesn t do something different every time. It didn t write itself; you wrote it, so take responsibility for it. Even if an error at first appears not to be your fault, it s strongly in your interest to assume that it is. That assumption helps you debug: It s hard enough to find a defect in your code when you re looking for it; it s even harder when you ve assumed your code is error-free. It improves your credibility because when you do claim that an error arose from someone else s code, other programmers will believe that you have checked out the problem carefully. Assuming the error is your fault also saves you the embarrassment of claiming that an error is someone