CONTRIBUTING.md

Contribute

Please follow these Lua-isa-simple-language-so-lets-keep-it-simple c onventions:

• Source code
  • All source code in one file.
    • All locals listed at top;
    • Application specific code at top;
    • General utilities at bottom,
    • Unit tests under nearly everything else, inside the Eg variable.
    • Second last is the main function to be called if this code is not included into another library:
      • And I test for that using not pcall(debug.getlocal, 4, 1).
    • Finally, there is a return statement that exports the more useful parts of the code.
  • No globasl (so keep the list of locals at top of file up to date).
  • The the local handles information and defaults shared across all functions and classes.
    • And this variable is initialized by parsing the Usage section of this help text/
  • Minimize use of the local keyword (so ugly)
    • Use it once at top of file.
    • Then (usually) define function locals as extra input arguments.
  • Indent code with 2 characters for tabs.
  • Using classes to divide the code.
    • Update the non-class library code rarely (since that is functions global to the module).
    • Update the class code a lot.
  • Classes:
    • Use classes for polymorphism.
    • Don't use inheritance (adds to debugging effort).
    • Classes are created by assigning some defaults to a global value;
      e.g. Emp={lname="", fname="", add=address() }
    • Class constructors are lower case functions that call isa(X) (where X is some class).
      • Typically for some Klass, the constrictor is the same name, starting with lower case (e.g. klass).
      • Constructors often use the idiom new.x = y or the.zzz.y where y is a parameter- S