感觉对现在的初级程序员很有帮助。

Guidelines for good behavior
摘自MM.com
Behaviors are powerful because they let one developer create scripts that others can easily use and reuse. As a result, a typical behavior is used by multiple developers, some of whom are not Lingo programmers.

The following are some useful guidelines for authoring a set of behaviors that are easy and predictable to use by others:

Save and distribute behaviors in a separate cast library. The behaviors are easier to distribute and the user can't accidentally modify the original behavior.

Provide a ReadMe file that describes all the behaviors. A field cast member at the beginning of the behavior library is a good place for this. Users could get the same information by reading the descriptions of behaviors in the Behavior Inspector and scrolling through behaviors, but scanning one list is easier than reviewing individual entries.

Provide a comment block, describing the overall structure of the behavior and hints about how to modify it, at the start of each script. These comments should contain advice for other Lingo programmers who are editing the behaviors script, not for the end user. Even just a few lines about which handlers are called from outside and how execution flows through the handlers can be a great help to users when they first study a script.

Try to make the behavior's Lingo as easy to understand as possible. This can be a challenge with complicated behaviors that require built-in error-checking. For example, a hypertext behavior may need to verify whether the behavior is attached to a field. Keep in mind that the added scripting makes the behavior's script more difficult to understand, and requires even clearer comments.Sometimes you can get around this by using a separate error checking routine when the behavior begins. This lets you put some of the "challenging" Lingo in a subroutine at the bottom of the script.

Encapsulate a behavior's properties and global variables as much as possible. A behavior can be used in many different environments, so the more contained it is, the better. Global variables can introduce crosstalk problems when the same variable name is unintentionally used by different behaviors. Minimize this possibility by giving global variables very specific names, such as gCurrentPositionVariableNumber23 . If data must be outside a script, consider using a single global list of variables for the entire behavior library and treat each variable as a property in the list. No matter how many behaviors in the library are used, each behavior still deals only with a single global variable.

Use unique IDs when calling handlers outside a behavior. For example, the sendAllSprites command sends a custom message to all current sprites, which could create unexpected results if behaviors from different sources have handlers with the same name. Prevent problems by avoiding simple handler names, which are more likely to be duplicated by other developers. For example, it's much less likely that another developer would name a handler teamDeveloperInit rather than Init