view doc/policies.txt @ 0:d547009c104c

Repository creation. committer: Diggory Hardy <diggory.hardy@gmail.com>
author Diggory Hardy <diggory.hardy@gmail.com>
date Sat, 27 Oct 2007 18:05:39 +0100
parents
children 9a990644948c
line wrap: on
line source

This is a collection of all coding policies for the mde engine as a whole. Policies for individual packages should be put in the individual package directory or elsewhere.

These are principles, not cast-iron rules, but should generally be adhered to.


Coding conventions: I mostly follow those provided in the D specification. Generally indent with four spaces. Use british or american (or other) spellings as you like, but BE CONSISTANT at least within packages. I generally break lines at 100 chars to prevent overlong lines (particularly documentation); this isn't critical but provides a good guide and keeps text looking reasonable.


Package design principle: use a separate package for each module of the engine. In most packages where there is only one module (file) imported by other parts of the engine, that module should have the same name as the package and be designed to have a standardised interface to the package so that the package could be replaced with another as a drop-in replacement (written with the same interface). Of course in many cases it may not be possible to swich one package for another quite this easily, but holding to this principle should at least minimise the amount of work necessary when doing so.


Engine-wide initialisation and cleanup should be handled or invoked by mde.init.Init's CTOR and DTOR methods where this is viable.


Logging should be handled by tango's Logger class. A logger with the name mde.package.module or mde.package.module.X where X is a symbol within the module should be used for each module. Thrown errors should be documented primarily by a log message rather than by returning a message within the exception, to keep logging consistant for both thrown errors and other messages. In general the levels should be used as follows:
	Trace	Where required or thought highly useful for debugging
	Info	Sparingly, for informational purposes (e.g. when parsing a file). Should not be used per-frame.
	Warn	For small errors which can be overlooked, even if they may cause bigger problems later.
	Error	For errors which cut-short a (reasonably large) operation (e.g. reading a file), but do not directly cause the program to terminate.
	Fatal	For errors directly (i.e. definately and almost immediately) ending the program.


Thrown errors should use a class specific to at least the package involved to enable specific catching of errors. Exception classes should be defined within a module exception.d in the package directory. Exception classes should all contain a this() CTOR and possibly a this(char[] msg) CTOR.