With modularizations comes the next important area of good form: using a solid naming convention. There are several approaches, but the more popular and easier form is the compounding of capitalized words to describe the module's purpose. For example, the modules in the credit application example are FormValidation, CreditCalc, FraudChk, and so on. These names help future programmers quickly understand code by using valid names for the modules. It is not a good idea to name code as Blink182Rocks or FinanceSUCKS even if this amuses you, but it is amazing how often an error dialog occurs that will display the offending module. A corollary of Murphy's Law is the more a programmer can get into trouble, the increased probability of the wrong person seeing an offending error, so that finance person who cuts the payroll checks will likely see your amusing naming convention.
Along with naming modules comes the naming of variables used in the code. The same technique used for naming modules works for variables as well, but change the first character to lowercase because it helps distinguish a variable from a module call in the code. Again, try using good nouns to describe the variable and avoid names that later may cause confusion (for example, theFlag, theCounter, and so on). Try using more descriptive names such as flagBadCredit, count2LastJob, and so on. Again, fight the urge for bad naming conventions such as flagTheDeadbeat, countTimesBeenFired, and so on.