Share this Page URL

Part IX: Finishing A Project > DEBUGGING - Pg. 547

547 Chapter 33. DEBUGGING IN THIS CHAPTER Writing Good Code Using the Lingo Debugging Tools Using the Watcher Testing Your Code Source movies for this chapter can be found on the CD-ROM in the "Book Movies" folder under folder 33. If you create a Director movie that has more than a few lines of Lingo in it, chances are that you will have to do some debugging. This means, literally, getting rid of bugs. Bugs can be as obvious as error messages generated by a faulty Lingo line, or as vague as "something just not working right." Note The reason program errors are called "bugs" is that the first bug was actually, well, a bug. An early computer produced an error when a moth flew in and short-circuited it. The name stuck. WRITING GOOD CODE An ounce of prevention goes a long way when programming. This means commenting your code, using descriptive handler and variable names, and dividing your code into sensible script members. Note You can also use commenting to temporarily deactivate a line of code. This is called com- menting out. Well-written code has much less chance of containing an error. If it does contain bugs, well-com- mented code increases the chance that these bugs can be located and fixed. Commenting Your Code Knowing when to comment in your code is the trick. You can't add code comments for every line, because it clutters up your Script window and makes it even harder to read. At the same time, no commenting at all makes it very hard to debug or to alter your code in the future. A comment is anything on a line that follows a double dash: (--). You can place comments in lines by themselves, or follow lines of actual code with a comment. You can add three types of comments to your code. You can write blocks of comments before a handler or a section of code, write comment lines before a line or group of lines, or write a short comment at the end of a line of code.