STYLE

Rules:

1. Policy is the enemy of prudence.
	- That means use your judgment above all else.
	- Whatever you do, be consistent about it. Random badness is harder to fix with a script.
	- Unless it pains you, try to match the style that already exists as much as possible.


2. Tabs Before Spaces.
	Tabs are used to establish the current bracket {} level. Do not use tabs for anything else.
	Do not format things or make things pretty with tabs. Use spaces for all formatting and
	prettiness after the current tab-level, and do not mix them hence: spaces-after-tabs or
	tabs-before-spaces.

	Goal: Code should appear as originally intended with any tab setting, whether it be 2, 4 or 8, etc.


3. No circular dependencies. (hint: Break it down).
	- No header include guards except on some header exposed to an end-user.



Style:


A. Formatting:
	- Allman brace style.
		- You can use " } else { "
	- Function definitions have two newlines between them.
	- Use whitespace liberally, but not more than 1 blank line for most else.
	- TABS BEFORE SPACES.


B. Always be covered by RAII, it's your alibi:
	- Use exceptions liberally. For an IRC project, the relative overhead of a catch is trivial...
		  ex: User sends !command with 2 out of 3 required arguments: don't tango with tabs and 
		  if() the number of arguments, just let the bad access throw, etc.

		- Avoid naked try/catch blocks. It's best to use function try, second-best to use loop/if-try.


C. Order everything by dependency:
	- In class declarations this means if foo() calls bar(), foo() is listed BELOW bar().
		- Classes start private. The ideal class has one "public:" label somewhere in the
		  middle, and no other labels necessary (this is obviously not a rule...).
		
	- For class definition files: the order is the REVERSE OF THE CLASS DECLARATION.
		- The definition file should open to the constructor at the top.