This provides general coding guidelines for Gawati code. This document
covers different programming languages used in Gawati: XQuery (.xql,
.xqm), JavaScript (.js), Java (.java). The objective of having
guidelines is to keep the code-base consistent and readable which is a
critical part keeping the code maintainable and manageable.

The code must use 4 spaces (instead of a tab) for indentation, except
for third party libraries (e.g. XSLTforms, YUI). Most modern code
editing tools support mapping a tab to 4 spaces. Every logical depth
level in the code needs to have an indent. There should be no whitespace
at the end of the line.

Comments need to talk about the “why”. This is useful not just for
others but for yourself when you read the code at a later time. They
need to be well written and clear and need to state a date and an author
if it is important commentary worth revisiting. For such revisit
comments, a format has been specified below.

Use Revisit comments for code that is temporary, a short-term solution
to be reworked, or for code on which there is still questions to be
resolved or understood. Multiple related Revisit comments (that use
same label) may be used across the project source, and across
different languages.

A Revisit comments should have a:

!+ : must explicitly start with these 2 characters

label : for easier grepping, and to be able to relate multiple comments across the project source (even in different languages)

author identifier : so others know who to follow-up with if needed, this can be the github handle of the committer.

date : so it is easier to judge relevance and status at a later time

description : should also indicate what conditions/events would render the comment obsolete.

The below are coding guidelines of how the code is to be strucutured and written. The reason for doing this is to have consistent and readable code. Many programmging languages and frameworks provide multiple ways of doing the same thing - for e.g. in React JS you can declare components either declaring a class directly, or by calling a spefific createClass api, both approaches may look correct, but both result in different looking code – which reduces readability. These coding guidelines below for different languages and frameoworks encourage uniformity and consistency.