Update the style guide to mention that we're using clang-format now.

diff --git a/STYLE.txt b/STYLE.txt
index 195883c760e4723d1ba0e038f3e02267e82c38b5..14a939d369f895915b20c0b1e03652846514030d 100644 (file)
--- a/STYLE.txt
+++ b/STYLE.txt
@@ -4,22 +4,22 @@ When changing the style, commit that separately from other changes.
 For new code and major changes to a function, switch to the official json-c style.\r
 \r
 Official json-c style:\r
+\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 indentation 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
+Formatting is tab based; previous attempts at proper alignment with\r
+spaces for continuation lines have been abandoned in favor of the\r
+convenience of using clang-format.\r
+Refer to the .clang-format file for details, and run the tool before commit:\r
+\r
+    clang-format -i somefile.c foo.h \r
+\r
+For sections of code that would be significantly negatively impacted, surround\r
+them with magic comments to disable formatting:\r
+\r
+    /* clang-format off */\r
+    ...code...\r
+    /* clang-format on */\r
+\r
 \r
 Naming:\r
 Words within function and variable names are separated with underscores.  Avoid camel case.\r
@@ -29,3 +29,4 @@ Other:
 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
+\r