Add a brief style guide. Address Issue #257.

diff --git a/STYLE.txt b/STYLE.txt
new file mode 100755 (executable)
index 0000000..e5acd14
--- /dev/null
+++ b/STYLE.txt
@@ -0,0 +1,31 @@
+In general:\r
+For minor changes to a function, copy the existing formatting.\r
+When changing the style, commit that separately from other changes.\r
+For new code and major changes to a function, switch to the official json-c style.\r
+\r
+Official json-c style:\r
+Aim for readability, not strict conformance to fixed style rules.\r
+These rules are not comprehensive.  Look to existing code for guidelines.\r
+Indentation is tab based, with continuations of long lines starting with tabs then spaces for alignment.\r
+Try to line up components of continuation lines with corresponding part of the line above (i.e. "indent -lp" effect), but avoid excessive identation tha causes extra line wraps. \r
+ e.g. (T=tab, S=space):\r
+TTTTsome_long_func_call(arg1, arg2,\r
+TTTTSSSSSSSSSSSSSSSSSSSarg3, arg4);\r
+TTTTsome_reallly_really_long_func_name(arg1,\r
+TTTTTarg2, arg3, arg4);\r
+There should be a space between "if"/"while" and the following parenthesis.\r
+"case" lines are indented at the same level as the "switch" statement.\r
+Commas are followed by a single space.\r
+Include spaces around most non-unary, non-postfix operators, "=", "==', "&", "||", etc...\r
+Function calls have no space between the name and the parenthesis.\r
+Curly braces go on their own line.\r
+Curly braces may be omitted.\r
+\r
+Naming:\r
+Words within function and variable names are separated with underscores.  Avoid camel case.\r
+Prefer longer, more descriptive names, but not excessively so.  No single letter variable names.\r
+\r
+Other:\r
+Variables should be defined for the smallest scope needed.\r
+Functions should be defined static when possible.\r
+When possible, avoid exposing internals in the public API.\r