>>Keep your life simple and don't do that. Then you won't have to wonder which module has control.
>
>You guys are boring... Do not use reserved words, do not use the same procedure name, do not use form sets... no sense of adventure whatsoever!

More items to add to the fun:
* Use macros whereever possible
* Code like you've never left dBASE III (you never know if you'll ever have to run them in the old dBASE III environment)
* Re-use identifiers as soon as they're avaialble (no sense in wasting a perfectly good variable/procedure name)
* Rather than alias name, always use workarea names
* Hard-code everything.
* Always shorten keywords to the shortest possible length ("to save disk space" and do demonstrate that "you're a *real* pro")
* Variation on macro bit: instead of arrays, you "fake" them by having "base" name and embedded "subscript" value. For example:
* Since grids didn't exist in dBASE -- "simulate" their behavior with BROWSE windows. With a bit of tweaking, you can "chop off" the borders by embedding a window within a window.
* If you must insist on having arrays, always use parenthesis and never the square brackets, and make sure you've used same name for array as well as UDF.
* If you are going to use the advanced FoxPro structures, find new ways to abuse them. Do things like RETURN inside FOR loops or in WITH..ENDWITH blocks.