Debugging

Introduction

Programs may not work, or not work correctly, for a variety of reasons. There are two main types of errors in programs:

  • Syntax error - an error in the syntax (or grammar) of the language/program. For example, mistyping or a keyword/command or not including a required comma or double quote. Syntax errors often cause the program not to run and an error message to display instead.
  • Semantic - an error in the logic or algorithm of the program. Programs with a semantic may still run, but not run correctly or produce the desired output.

Programs may not run, or not run correctly, due to numerous other possibilities, depending on the language, operating system, and many other factors.

This section will review a variety of these factors.


General tips to debugging:

  • Carefully review any error message or code that is displayed and think about what might cause this. Take your time.
  • In many editors/IDEs, syntax is highlighted with color and there is consistency with these colors. Look for color issues, e.g. a command that should be blue is black or yellow.
  • Review the line number where the error message is indicating there is an error. If you do not see the error, look on the line above this line (or the next few lines above)
  • Look for simple spelling mistakes in commands (look up the commands themselves - for example in Google, handout, or a reference book) to see if you've used the command and its syntax correctly.
  • Look for special characters that may be missing or in the incorrect location. For example,
    • if you have three opening parentheses in an math formula ((( do you have three closing parentheses to the right?
    • If you are nesting code in some languages, do you have both the opening and closing curly braces {}
  • If you are getting no output or incorrect output, try to print out the contents of several variables or output text inside of decision and loop statements to see what is occurring when the programs runs.
  • Coding and debugging are both detail-oriented. Every character, even one character can cause a program not to run. If your program has a syntax error and will not run, take your time, spent a minute or two looking at a line, and review working programs and examples to find the error.
  • Coding and debugging are also both systematic processes. Debugging a programming is diagnostic process simialir to that a physician would use to diagnose a problem with a patient or a mechanic would use to diagnose a problem with a vehicle. You are diagnosing a problem with a program.
    • To do this, you develop and follow a set of things you check, one by one, to look for (diagnose) the problem.
    • This also involves a process of elimination where you begin to eliminate issues that are not causing the problem until, in the end, you will evenutally find the cause.
    • Coding in small chunks, for example, one function at a time, or ten lines at a time. Then, you only have to debug this amount of code.
    • Backup your program every so often when it is in a working state. Then, if you program every begins to have an error you can't find your debug, you can revert back to the previous version. But, recall, you may also be able to revert by using the Ctrl-Z until shortcut in Windows.
    • If the error occurs when you have a larger program, comment out blocks of code, such as functions or ten lines at a time, and then run the program. If the error goes away, the code you commented out is where the error is. If the error does not go away, the error still exists - keep those lines commented out and then comment out more blocks until you find the error. This is much like the tests physicians give until they diagnose the patient problems. The tests come back ok, which rules out as an issue, and they keep testing until they find the issue.
  • Coding and debugging require persistence. Creating a program and debugging it may take hours, days, or more depending on its size and complexity. Artists do not create scuptures in minutes, rooms are not remodeled in minutes and programs are not created or fixed immediately. Be logical and systematic in your work, enjoy it, even the challenging aspects.

Operating System Items

if you are using a language that has a lot operating system interactions, such as HTML and PHP, there are a number of other tasks that are beneficial to review when debugging.

  • Check if the filename is spelled correct or as you think it is.
  • Remember the filenames on Windows computers are not case sensitive, while filenames on Linux/Unix servers are case sensitive. Using all lowercase filenames may be a practice that prevents case issues.
  • Be sure you are editing the same file you are running. Having good organization to your files in folders is critical. If you are getting confused as to where your files are at, take some time to organize them and know where everything is at.
  • If you are using a server, be sure the file permissions are correct. For example, 701 on Linux folders and 604 on files are good permission settings. A common error message you will get if permissions are not correct is "Permission Denied" or an image will not display on the web page.
  • If working with HTML and CSS, have you saved the most recent changes in your files and refreshed the web browser.

In the end, if you do not find the error, take a break - maybe for a few hours or a day. Very often you will think of the solution a few hours later while not even thinking about it or find it the next day shortly after picking the code back up.