Code Conventions

EggPlant adheres to the following code conventions...

One API per Include

Due to the amount of code in EggPlant, APIs have been separated out in to multiple JS includes. Wherever possible, there is only one API per include.

Files are named based on the API they contain or extend. For example, Map.Sector.js adds a Sector API to the Map API.

API Sandboxes

Each API is defined in a self-running named closure (a "sandbox"), for example:

void (function SomeAPI() {
   // API defined here
})();

Naming the closure helps generate better error messages, voiding it's return value helps avoid the closure appearing on the global scope should a typo be made within the code.

Dependency checking

Using features in Util.js, each API performs dependency checks at the start of it's sandbox and only registers itself available at the end of the sandbox. For example:

void (function SomeAPI() {
  var self = {
    file: "Process.js",
    ver : 0.3
  }

  var dependencies = {
    "Util.js": 0.8,
    "Diag.js": 0.1
  }

  uNeeds(self, dependencies);
  // API defined here
 
  uProvide(self);
})();

Named functions

Wherever possible all functions are named, even if they are assigned to named object properties, to improve error reporting.

For example:

var foo = {};
 
foo.bar = function bar() {
  // do stuff
}

Filter and Sort routines

The following naming conventions are used for array filters and sort routines:

Array method	Naming convention	Example
`array.filter(fn)`	toWhatever	`tasks = tasks.filter(toTaskRuntime)`
`array.sort(fn)`	byWhatever	`tasks.sort(byTaskRuntime)`

Commonly used JS methods

EggPlant makes extensive use of the following common JS methods which you should familiarise yourself with before making any code alterations:

Object.keys(obj) – get a list of all enumerable own property names of object "obj"
array.forEach(fn)– run a function against each element in an array

Use Process API

The Process API is used extensively, with practically all code execution being called from within processes. This helps significantly reduce game lag and also allows use of the extensive range of diagnostics.

Any non-process custom events are used to trigger a process or at the very least void the global timeRemaining property as soon as possible.