listing and errors
Compilers can produce listings. These will add extra information to your original source code file. Many compilers have optional settings on what kinds of information are included. Of particular interest are errors. There are two basic kinds of errors in programming: (1) errors in typing a language and (2) errors in programming logic.
listings and errors
Compilers can produce listings. These will add extra information to your original source code file. Many compilers have optional settings on what kinds of information are included.
Of particular interest are errors. There are two basic kinds of errors in programming: (1) errors in typing a language and (2) errors in programming logic.
A mistake in a program is called a bug. This is an old engineering term, appearing in Thomas Edisons writings:
It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise this thing gives out and then that Bugs as such little faults and difficulties are called show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached. Thomas Edison
Many books incorrectly attribute the term bug to Grace Hopper. While she was working at Harvard Universitys Computation Laboratory, operators discovered a moth trapped in a relay in Harvards Mark II computer. The moth was taped to the log book. Hopper repeated the story for decades as the case of the first actual bug in a computer.
A compiler generated listing will only show errors in the typing (such as mistakes in spelling or punctuation) or incorrect use of the language (such as incorrect formation of an executable statement). These are known as compile time errors because they can be identified at the time the program is compiled.
You wont know about errors in programming logic until the program is actually running. These are known as run time errors. You will want to thoroughly test your programs to try to find any mistakes, but testing wont always reveal every error. There is an art to testing a program. Some of the best program testers dont even knw how to write a program, but they sure know how to find ways to break programs.
Errors vary in severity. In some cases the compiler may be able to correct errors of low severity for you. Some compilers let you control which errors are flagged, skipping over errors the compiler can correct. You should strive to eliminate all errors from your source code listing, even if the compiler is able to correct them for you.
Compilers also often produce warning. These are things that are not necessarily a problem. Some compilers let you decide whether to have warnings listed or not, and in some cases even let you decide which kinds of warnings are listed. You should strive to eliminate all warnings from your source code listing.
Many compilers have the option of inserting line numbers into your listing. These line numbers can be very useful in tracking down compile time errors. Note that it is rare that the compilers idea of line numbers will end up exactly matching the physical lines in your original source file. The line numbers are typically based on the languages statements. Comments and blank lines are rarely counted as lines in a source code listing. Multiple statements on a single line are usually identified by the number of the first statement on the same physical line.
Many compilers will give you the option of stopping after the first error is detected or attemting to continue to compile. Note that the first error may confuse the compiler enough that it starts reporting bogus errors. This is known as cascading errors (named after cascading waterfalls).
Many compilers will give you the option of viewing the symbol table. This is a list of the identifiers (procedures, functions, labels, constants, variables, etc.). There are many uses for a symbol table in correcting your source code. As one example, it is possible that you misspelled an identifier. The code may be correct from a lexical point of view (with no errors listed), but wont work at run time. You might spot the incorrect spelling in your symbol table.
You may want to purposely introduce a few errors into your Hello World program and see how your compiler reports them.
Compilers are notorious for cryptic error messages. The error messages are generally not standardized for any particualr language, but vary with each compiler. With practice, you will learn to read the error messages and use them to find and identify your mistakes.
A few days after initially writing this chapter, I spoke to a man who had been a BASIC programmer during the 1980s. He recounted that he had attempted to write a FORTRAN program and spent three weeks trying to track down a single error: accidently replacing a period with a comma. Sadly, this is typical of the debugging abilities of most programmers. There are very few places in FORTRAN where replacing a period with a comma will still produce a running program. It really shouldnt have taken more than a few minutes to track down the exact line with the error and then identify the incorrect character through visual examination. If the program did compile and run, it shouldnt have taken too much time to pin down the location of the error and then spot the incorrect character. Being methodical is a great way to not only locate bugs but also to avoid them in the first place.
While software errors may be inevitable, good programming practices can dramatically lower the number of errors.
Structured programming was created as a method to eliminate programming errors. It tended to eliminate many errors caused by sloppy coding and reduced the complexity of some kinds of programming to the point that mistakes were less common.
Object oriented programming was created to both allow for faster creation of complex software and to reduce the number of mistakes in complex software. While these characteristics do apply to skilled programmers, for the vast majority of current programming, object oriented programming doesnt actually cut down on errors, but instead limits the damage of errors. That is, a typical programmer will still make as many mistakes as ever, but the mistakes will be isolated and wont cause havoc on the larger system.
40. There are two ways to write error-free programs; only the third one works. Alan Perlis, Epigrams on Programming, ACMs SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13
61. In programming, as in everything else, to be in error is to be reborn. Alan Perlis, Epigrams on Programming, ACMs SIGPLAN Notices Volume 17, No. 9, September 1982, pages 7-13
free music player coding example
Coding example: I am making heavily documented and explained open source code for a method to play music for free almost any song, no subscription fees, no download costs, no advertisements, all completely legal. This is done by building a front-end to YouTube (which checks the copyright permissions for you).
View music player in action: www.musicinpublic.com/.
Create your own copy from the original source code/ (presented for learning programming).
Because I no longer have the computer and software to make PDFs, the book is available as an HTML file, which you can convert into a PDF.
Names and logos of various OSs are trademarks of their respective owners.