Debugging, Error Checking, and Naming Conventions


Nothing is more frustrating than putting an hour , to say nothing of a day or two, into the writing of a script, run it the first time only to see line upon line of errors fill the Script Editor s history area. The bad news is that these errors, called bugs in coding vernacular, are inevitable. Bugs are bound to happen to even the best scripters. The good news is that every bug is fixable, and with the aid of the Stack Trace and Line Numbering is a relatively painless practice. Notice we said relatively painless. Debugging , the practice of finding and eliminating these bugs, can sometimes be a frustrating process, but in time every scripter learns the mistakes he commonly makes and can spot them quite quickly.

Note  

The programming term bug comes from the very early days of computer programming, which of course was only 60 years ago. In those ancient times, transistor , vacuum tubes were used to complete circuits, which would then provide a calculation of a mathematical problem. Every so often, an insect would find its way into the room sized -computers and complete a circuit, giving an incorrect answer and frying itself in the process. Hence, today when we have an error in our calculations or code, we have encountered a bug.

The process of writing a script generally produces two types of errors, functional errors and syntax errors. Functional errors are often not reported by Stack Trace. They are not errors in the sense that they don t work; rather, they simply do not produce the result intended by the script s author. Although occasionally a functional error will be reported , such as attempting to carry out a command on an invalid selection type, it is often quite a challenge to track them down. Syntax errors are much more common than functional errors, most often the result of a simple typo, such as misspelling a command word or forgetting to end a line with a semicolon. Note that occasionally a syntax error will produce a functional error, such as getting the x and y components of a vector mixed up. These are often the hardest to track down, especially in larger scripts, simply because of the overwhelming amount of text. This is yet another reason to separate as many actions as possible into separate procedures, allowing the debug process to be modular.

A powerful technique used to prevent script failures is error checking . Oddly, error checking is actually used to create errors, but through the MEL command error . If a script requires a specific action to be taken by the user , such as having a single polygonal object selected, or requires the Maya environment to be set in a specific manner, such as having the angular units in radians, a scripter can check for these qualities with some if statements. In Example 5.10 we see a typical error check, in this case to see if the user has selected any objects, by seeing if the variable $selList , having been previously declared and assigned the selection list, has any items in it.

Example 5.10: Using a conditional statement to error check.

 if ( `size $selList` < 1)         error "Please select at least one object." 

The MEL command error is used to create a specific error feedback. It both immediately terminates the further execution of a script and gives the users feedback as to what they have done wrong. error confirmDialog if

Error checking does not always require an error statement. There are situations in which a script wants to confirm an action. This is often done in situations where undoing a script is not possible, like batch processing ( and therefore saving ) files, or when proceeding will take an inordinately long period of time. Using the confirmDialog command, and then querying the user s response in an if statement, allows for this capability. Dialogs are covered in depth in Chapter 11, Customizing the Maya Interface.

Using error checks is one of the hallmarks of an experienced scripter. They both prevent a script s user from possibly harming the data and provide a way for the needs of a script to be easily communicated to a user. Through the careful implementation of error checks, a scripter can guarantee that when the time comes to execute the real body of a script, it is operating on both the exact data it should, and in the environment for which it was designed, allowing the script to function exactly as planned.

The final practice commonly used by skilled programmers is that of a standardized and cohesive naming structure for all components of a script. This includes variables , procedures, and the names of the script files themselves . Script and procedure names should be both distinctive and descriptive. If the tool being created will be composed of multiple scripts or procedures, especially if they are global procedures, add either a prefix or suffix to the name to prevent the wrong procedure from being called, as well as to identify the separate scripts as part of a larger whole. The latter reason leads us to more often than not use a prefix, to allow for easy sorting and grouping within a file browser or system call. For example, a tool to create an ocean environment might have a main script called buildStormySea.mel , but with separate scripts for building the user interface and for providing help and instructions, called bss_ui.mel and bss_help.mel , respectively. Many scripters also prefix their scripts with either their own initials or those of their production facility. This is done to allow tools similar in functionality and naming to existing tools to exist side by side. An example might be a script called dps_pointConstraint.mel , which could produce an effect similar to Maya s point constraint, without overwriting the standard functionality of the Maya command pointConstraint .

Variables must also be named carefully , most particularly in the case of global variables. Since global variables are visible outside of a script, they can easily conflict with other global variables declared in other scripts. With global variables, it is also important to remember that all variables declared at the Command Line, Script Editor, or Command Shell not contained in a command group are global.

Variable names should be descriptive, but it is often desirable to keep them short to allow for quicker programming. For example, it can become quite a hassle to type in a variable named $polygonSelectionList over and over in a script rather than something just as descriptive but shorter, such as $polySelList or even $polySel . Having long variable names is also a common cause for errors within a script. A scripter is more likely to misspell a long variable than a short variable.

This is yet another situation where an external, dedicated text editor designed for programming can aid in the creation of MEL scripts. These external editors often have auto-completion features that allow for highly descriptive long variable names while speeding the programming process and avoiding spelling errors.




The MEL Companion
The MEL Companion: Maya Scripting for 3D Artists (Charles River Media Graphics)
ISBN: 1584502754
EAN: 2147483647
Year: 2003
Pages: 101

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net