• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Part IV: Appendixes > Fuse Rules

Fuse Rules

Fuses follow specific rules of use and employ standard naming prefixes (shown in Table A.3). Following the rules shown in Table A.2, your code is more easily reused, debugged, extended with new features, and provides a level of self documentation.

Table A.2. Fuse Rules
Rule Number Description
Rule 1 A fuse is length challenged. Code should be short and concise. Try to fit each fuse’s code on one screen.
Rule 2 A fuse is reusable. Fuses should only contain one atomic action, which is carefully defined.
Rule 3 A fuse by any other prefix isn’t a fuse. All fuses must contain a prefix (see Table A.3 for a list) that denotes its role.
Rule 4 A fuse can be a naming rebel. Try to follow the standard naming practices and fuse types. However, if your environment needs another prefix, use it.
Rule 5 A fuse has a sense of self. Some types of code should not be in certain types of fuses. For example, display code should only be used for display fuses.
Rule 6 Fuse types congregate together. Fuses can be stored in their own subdirectories below the circuit.
Rule 7 A fuse contains Fusedocs. Fusedocs guide the fuse, determining its role and available variables. Fuses cannot live without Fusedocs.
Rule 8 A fuse is clueless. Fuses should not be tightly integrated into other fuses, nor should they rely heavily on external resources.
Rule 9 A fuse should watch its back. Fuses might get bad data or expect different datatypes than that which is provided. Code accordingly and expect the unexpected.
Rule 10 A fuse has a good name. In addition to prefixes, fuses should be named explicitly. dsp_loginForm.cfm is better than dsp_clSm_frm.cfm.



Not a subscriber?

Start A Free Trial

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint