Langband style

Currently very little is documented or in place, some coding guidelines exist however to make the code easier to understand:

• All code should be lowercase whenever possible despite uppercase names in documents. The uppercase is used to make the code stand out in the text, but code doesn't need to stand out in code.
• All constants (DEFCONSTANT) are put in-between +-signs, ie +pi+
• All global dynamic variables (use DEFVAR, not DEFPARAMETER) are put in-between *-signs, ie *player*
• All predicates have a ?-suffix, ie player-dead? and should have no side-effects
• All functions which induce side-effects on their arguments should have a !-suffix, ie equip-player!
• All functions which manipulate global variables should have a &-suffix, ie init-environment&
• Functions that are meant to be internal to their file and not be used outside or exported should use a % prefix. Ane example is %birth-input-char in birth.lisp which is only input to birth-functionality and is uninteresting to others.
• All game-related symbolic constants should be put between < and >, ie '<RANGER>
• All functions and macros with a DEFINE- prefix implicitly have global side-effects, ie define-monster. They will also return the object they have defined. Do not use the & suffix.
• The prefix MAKE- are restricted to non-sideeffect constructors of objects, ie wrapped MAKE-INSTANCEs. An object is returned from this kind of function.
• Functions whose purpose is to "add" something to "global" tables, maybe from a DEFINE- function/macro, should use the ESTABLISH- prefix, and return the object in question. A & suffix is expected. These should not be called by variant code though, variants should use DEFINE-. However, if it seems reasonable with a SETF-match to a GET- function instead of an ESTABLISH-, use SETF.
• Macros which create an environment to execute code in whould use a WITH- prefix, and if it needs a function to implement itself it should use a INVOKE-ON- prefix. An example is: WITH-DUNGEON and it's implementation in INVOKE-ON-DUNGEON. These macros are allowed to create side-effects on their arguments.
• Variant-code should use their own special prefix for internal functions, variables, etc. As an example, all vanilla functions and variables use the VAN- prefix. Loading variant-code is also allowed to induce side-effects, ie registering the variant in appropriate places.
• Code which is expected to be common to all variants should be put in lib/common and have a COMMON- prefix. Loading lib/common might also have side-effects.
• Identifiers should preferrably be lowercase strings.
• Functions which need interactive input might want to have a QUERY- prefix.
• Factory-methods, with no side-effects (except maybe caching) and which require no interactivity, should use the PRODUCE- prefix. Factory-methods should when possible depend on at least the variant, to be able to control it.