2020-06-14 12:02:19 -04:00
|
|
|
# Uncrustify-0.71.0_f
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
2022-08-29 02:50:49 -04:00
|
|
|
# IMPORTANT: Output is different if using Uncrustify 0.73 or newer, and config file format has changed in newer versions.
|
|
|
|
# Use version 0.71 or 0.72 to get matching code formatting.
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
# General options
|
|
|
|
#
|
|
|
|
|
|
|
|
# The type of line endings.
|
|
|
|
#
|
|
|
|
# Default: auto
|
|
|
|
newlines = auto # lf/crlf/cr/auto
|
|
|
|
|
|
|
|
# The original size of tabs in the input.
|
|
|
|
#
|
|
|
|
# Default: 8
|
|
|
|
input_tab_size = 8 # unsigned number
|
|
|
|
|
|
|
|
# The size of tabs in the output (only used if align_with_tabs=true).
|
|
|
|
#
|
|
|
|
# Default: 8
|
|
|
|
output_tab_size = 8 # unsigned number
|
|
|
|
|
|
|
|
# The ASCII value of the string escape char, usually 92 (\) or (Pawn) 94 (^).
|
|
|
|
#
|
|
|
|
# Default: 92
|
|
|
|
string_escape_char = 92 # unsigned number
|
|
|
|
|
|
|
|
# Alternate string escape char (usually only used for Pawn).
|
|
|
|
# Only works right before the quote char.
|
|
|
|
string_escape_char2 = 0 # unsigned number
|
|
|
|
|
|
|
|
# Replace tab characters found in string literals with the escape sequence \t
|
|
|
|
# instead.
|
|
|
|
string_replace_tab_chars = false # true/false
|
|
|
|
|
|
|
|
# Allow interpreting '>=' and '>>=' as part of a template in code like
|
|
|
|
# 'void f(list<list<B>>=val);'. If true, 'assert(x<0 && y>=3)' will be broken.
|
|
|
|
# Improvements to template detection may make this option obsolete.
|
|
|
|
tok_split_gte = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Disable formatting of NL_CONT ('\\n') ended lines (e.g. multiline macros)
|
|
|
|
disable_processing_nl_cont = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Specify the marker used in comments to disable processing of part of the
|
|
|
|
# file.
|
2020-06-14 12:02:19 -04:00
|
|
|
# The comment should be used alone in one line.
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
# Default: *INDENT-OFF*
|
|
|
|
disable_processing_cmt = " *FORMAT-OFF*" # string
|
|
|
|
|
|
|
|
# Specify the marker used in comments to (re)enable processing in a file.
|
2020-06-14 12:02:19 -04:00
|
|
|
# The comment should be used alone in one line.
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
# Default: *INDENT-ON*
|
|
|
|
enable_processing_cmt = " *FORMAT-ON*" # string
|
|
|
|
|
|
|
|
# Enable parsing of digraphs.
|
|
|
|
enable_digraphs = false # true/false
|
|
|
|
|
|
|
|
# Add or remove the UTF-8 BOM (recommend 'remove').
|
|
|
|
utf8_bom = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# If the file contains bytes with values between 128 and 255, but is not
|
|
|
|
# UTF-8, then output as UTF-8.
|
|
|
|
utf8_byte = false # true/false
|
|
|
|
|
|
|
|
# Force the output encoding to UTF-8.
|
|
|
|
utf8_force = false # true/false
|
|
|
|
|
|
|
|
# Add or remove space between 'do' and '{'.
|
|
|
|
sp_do_brace_open = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '}' and 'while'.
|
|
|
|
sp_brace_close_while = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'while' and '('.
|
|
|
|
sp_while_paren_open = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
#
|
|
|
|
# Spacing options
|
|
|
|
#
|
|
|
|
|
|
|
|
# Add or remove space around non-assignment symbolic operators ('+', '/', '%',
|
|
|
|
# '<<', and so forth).
|
|
|
|
sp_arith = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around arithmetic operators '+' and '-'.
|
|
|
|
#
|
|
|
|
# Overrides sp_arith.
|
|
|
|
sp_arith_additive = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around assignment operator '=', '+=', etc.
|
|
|
|
sp_assign = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around '=' in C++11 lambda capture specifications.
|
|
|
|
#
|
|
|
|
# Overrides sp_assign.
|
|
|
|
sp_cpp_lambda_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the capture specification of a C++11 lambda when
|
|
|
|
# an argument list is present, as in '[] <here> (int x){ ... }'.
|
|
|
|
sp_cpp_lambda_square_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the capture specification of a C++11 lambda with
|
|
|
|
# no argument list is present, as in '[] <here> { ... }'.
|
|
|
|
sp_cpp_lambda_square_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the argument list of a C++11 lambda, as in
|
|
|
|
# '[](int x) <here> { ... }'.
|
|
|
|
sp_cpp_lambda_paren_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between a lambda body and its call operator of an
|
|
|
|
# immediately invoked lambda, as in '[]( ... ){ ... } <here> ( ... )'.
|
|
|
|
sp_cpp_lambda_fparen = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around assignment operator '=' in a prototype.
|
|
|
|
#
|
|
|
|
# If set to ignore, use sp_assign.
|
|
|
|
sp_assign_default = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before assignment operator '=', '+=', etc.
|
|
|
|
#
|
|
|
|
# Overrides sp_assign.
|
|
|
|
sp_before_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after assignment operator '=', '+=', etc.
|
|
|
|
#
|
|
|
|
# Overrides sp_assign.
|
|
|
|
sp_after_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space in 'NS_ENUM ('.
|
|
|
|
sp_enum_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around assignment '=' in enum.
|
|
|
|
sp_enum_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before assignment '=' in enum.
|
|
|
|
#
|
|
|
|
# Overrides sp_enum_assign.
|
|
|
|
sp_enum_before_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after assignment '=' in enum.
|
|
|
|
#
|
|
|
|
# Overrides sp_enum_assign.
|
|
|
|
sp_enum_after_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around assignment ':' in enum.
|
|
|
|
sp_enum_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around preprocessor '##' concatenation operator.
|
|
|
|
#
|
|
|
|
# Default: add
|
|
|
|
sp_pp_concat = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after preprocessor '#' stringify operator.
|
|
|
|
# Also affects the '#@' charizing operator.
|
|
|
|
sp_pp_stringify = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before preprocessor '#' stringify operator
|
|
|
|
# as in '#define x(y) L#y'.
|
|
|
|
sp_before_pp_stringify = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around boolean operators '&&' and '||'.
|
|
|
|
sp_bool = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around compare operator '<', '>', '==', etc.
|
|
|
|
sp_compare = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside '(' and ')'.
|
2020-03-26 09:35:04 -04:00
|
|
|
sp_inside_paren = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between nested parentheses, i.e. '((' vs. ') )'.
|
2020-03-20 06:47:07 -04:00
|
|
|
sp_paren_paren = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between back-to-back parentheses, i.e. ')(' vs. ') ('.
|
|
|
|
sp_cparen_oparen = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to balance spaces inside nested parentheses.
|
|
|
|
sp_balance_nested_parens = false # true/false
|
|
|
|
|
|
|
|
# Add or remove space between ')' and '{'.
|
|
|
|
sp_paren_brace = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between nested braces, i.e. '{{' vs '{ {'.
|
|
|
|
sp_brace_brace = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before pointer star '*'.
|
|
|
|
sp_before_ptr_star = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before pointer star '*' that isn't followed by a
|
|
|
|
# variable name. If set to ignore, sp_before_ptr_star is used instead.
|
|
|
|
sp_before_unnamed_ptr_star = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between pointer stars '*'.
|
|
|
|
sp_between_ptr_star = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after pointer star '*', if followed by a word.
|
|
|
|
#
|
|
|
|
# Overrides sp_type_func.
|
|
|
|
sp_after_ptr_star = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after pointer caret '^', if followed by a word.
|
|
|
|
sp_after_ptr_block_caret = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after pointer star '*', if followed by a qualifier.
|
|
|
|
sp_after_ptr_star_qualifier = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after a pointer star '*', if followed by a function
|
|
|
|
# prototype or function definition.
|
|
|
|
#
|
|
|
|
# Overrides sp_after_ptr_star and sp_type_func.
|
|
|
|
sp_after_ptr_star_func = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after a pointer star '*', if followed by an open
|
|
|
|
# parenthesis, as in 'void* (*)().
|
|
|
|
sp_ptr_star_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a pointer star '*', if followed by a function
|
|
|
|
# prototype or function definition.
|
|
|
|
sp_before_ptr_star_func = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a reference sign '&'.
|
|
|
|
sp_before_byref = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a reference sign '&' that isn't followed by a
|
|
|
|
# variable name. If set to ignore, sp_before_byref is used instead.
|
|
|
|
sp_before_unnamed_byref = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after reference sign '&', if followed by a word.
|
|
|
|
#
|
|
|
|
# Overrides sp_type_func.
|
|
|
|
sp_after_byref = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after a reference sign '&', if followed by a function
|
|
|
|
# prototype or function definition.
|
|
|
|
#
|
|
|
|
# Overrides sp_after_byref and sp_type_func.
|
|
|
|
sp_after_byref_func = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a reference sign '&', if followed by a function
|
|
|
|
# prototype or function definition.
|
|
|
|
sp_before_byref_func = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between type and word.
|
|
|
|
#
|
|
|
|
# Default: force
|
|
|
|
sp_after_type = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'decltype(...)' and word.
|
|
|
|
sp_after_decltype = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space before the parenthesis in the D constructs
|
|
|
|
# 'template Foo(' and 'class Foo('.
|
|
|
|
sp_before_template_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'template' and '<'.
|
|
|
|
# If set to ignore, sp_before_angle is used.
|
|
|
|
sp_template_angle = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before '<'.
|
|
|
|
sp_before_angle = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside '<' and '>'.
|
|
|
|
sp_inside_angle = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside '<>'.
|
|
|
|
sp_inside_angle_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '>' and ':'.
|
|
|
|
sp_angle_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after '>'.
|
|
|
|
sp_after_angle = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '>' and '(' as found in 'new List<byte>(foo);'.
|
|
|
|
sp_angle_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '>' and '()' as found in 'new List<byte>();'.
|
|
|
|
sp_angle_paren_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '>' and a word as in 'List<byte> m;' or
|
|
|
|
# 'template <typename T> static ...'.
|
|
|
|
sp_angle_word = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '>' and '>' in '>>' (template stuff).
|
|
|
|
#
|
|
|
|
# Default: add
|
|
|
|
sp_angle_shift = add # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (C++11) Permit removal of the space between '>>' in 'foo<bar<int> >'. Note
|
|
|
|
# that sp_angle_shift cannot remove the space without this option.
|
|
|
|
sp_permit_cpp11_shift = false # true/false
|
|
|
|
|
|
|
|
# Add or remove space before '(' of control statements ('if', 'for', 'switch',
|
|
|
|
# 'while', etc.).
|
|
|
|
sp_before_sparen = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside '(' and ')' of control statements.
|
|
|
|
sp_inside_sparen = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after '(' of control statements.
|
|
|
|
#
|
|
|
|
# Overrides sp_inside_sparen.
|
|
|
|
sp_inside_sparen_open = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before ')' of control statements.
|
|
|
|
#
|
|
|
|
# Overrides sp_inside_sparen.
|
|
|
|
sp_inside_sparen_close = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after ')' of control statements.
|
|
|
|
sp_after_sparen = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between ')' and '{' of of control statements.
|
|
|
|
sp_sparen_brace = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space between 'invariant' and '('.
|
|
|
|
sp_invariant_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space after the ')' in 'invariant (C) c'.
|
|
|
|
sp_after_invariant_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before empty statement ';' on 'if', 'for' and 'while'.
|
|
|
|
sp_special_semi = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before ';'.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_before_semi = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before ';' in non-empty 'for' statements.
|
|
|
|
sp_before_semi_for = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a semicolon of an empty part of a for statement.
|
|
|
|
sp_before_semi_for_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after ';', except when followed by a comment.
|
|
|
|
#
|
|
|
|
# Default: add
|
|
|
|
sp_after_semi = add # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after ';' in non-empty 'for' statements.
|
|
|
|
#
|
|
|
|
# Default: force
|
|
|
|
sp_after_semi_for = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the final semicolon of an empty part of a for
|
|
|
|
# statement, as in 'for ( ; ; <here> )'.
|
|
|
|
sp_after_semi_for_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before '[' (except '[]').
|
|
|
|
sp_before_square = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before '[' for a variable definition.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_before_vardef_square = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before '[' for asm block.
|
|
|
|
sp_before_square_asm_block = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before '[]'.
|
|
|
|
sp_before_squares = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before C++17 structured bindings.
|
|
|
|
sp_cpp_before_struct_binding = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside a non-empty '[' and ']'.
|
|
|
|
sp_inside_square = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space inside a non-empty Objective-C boxed array '@[' and
|
|
|
|
# ']'. If set to ignore, sp_inside_square is used.
|
|
|
|
sp_inside_square_oc_array = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after ',', i.e. 'a,b' vs. 'a, b'.
|
2022-05-04 23:26:34 -04:00
|
|
|
sp_after_comma = add # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space before ','.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_before_comma = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (C#) Add or remove space between ',' and ']' in multidimensional array type
|
|
|
|
# like 'int[,,]'.
|
|
|
|
sp_after_mdatype_commas = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (C#) Add or remove space between '[' and ',' in multidimensional array type
|
|
|
|
# like 'int[,,]'.
|
|
|
|
sp_before_mdatype_commas = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (C#) Add or remove space between ',' in multidimensional array type
|
|
|
|
# like 'int[,,]'.
|
|
|
|
sp_between_mdatype_commas = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between an open parenthesis and comma,
|
|
|
|
# i.e. '(,' vs. '( ,'.
|
|
|
|
#
|
|
|
|
# Default: force
|
|
|
|
sp_paren_comma = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before the variadic '...' when preceded by a
|
|
|
|
# non-punctuator.
|
|
|
|
sp_before_ellipsis = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between a type and '...'.
|
|
|
|
sp_type_ellipsis = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space between a type and '?'.
|
|
|
|
sp_type_question = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between ')' and '...'.
|
|
|
|
sp_paren_ellipsis = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between ')' and a qualifier such as 'const'.
|
|
|
|
sp_paren_qualifier = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between ')' and 'noexcept'.
|
|
|
|
sp_paren_noexcept = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after class ':'.
|
|
|
|
sp_after_class_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before class ':'.
|
|
|
|
sp_before_class_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after class constructor ':'.
|
|
|
|
sp_after_constr_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before class constructor ':'.
|
|
|
|
sp_before_constr_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before case ':'.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_before_case_colon = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'operator' and operator sign.
|
|
|
|
sp_after_operator = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between the operator symbol and the open parenthesis, as
|
|
|
|
# in 'operator ++('.
|
|
|
|
sp_after_operator_sym = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides sp_after_operator_sym when the operator has no arguments, as in
|
|
|
|
# 'operator *()'.
|
|
|
|
sp_after_operator_sym_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after C/D cast, i.e. 'cast(int)a' vs. 'cast(int) a' or
|
|
|
|
# '(int)a' vs. '(int) a'.
|
2020-03-26 09:35:04 -04:00
|
|
|
sp_after_cast = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove spaces inside cast parentheses.
|
2020-03-26 09:35:04 -04:00
|
|
|
sp_inside_paren_cast = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between the type and open parenthesis in a C++ cast,
|
|
|
|
# i.e. 'int(exp)' vs. 'int (exp)'.
|
|
|
|
sp_cpp_cast_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'sizeof' and '('.
|
|
|
|
sp_sizeof_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'sizeof' and '...'.
|
|
|
|
sp_sizeof_ellipsis = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'sizeof...' and '('.
|
|
|
|
sp_sizeof_ellipsis_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'decltype' and '('.
|
|
|
|
sp_decltype_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (Pawn) Add or remove space after the tag keyword.
|
|
|
|
sp_after_tag = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside enum '{' and '}'.
|
|
|
|
sp_inside_braces_enum = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside struct/union '{' and '}'.
|
|
|
|
sp_inside_braces_struct = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space inside Objective-C boxed dictionary '{' and '}'
|
|
|
|
sp_inside_braces_oc_dict = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after open brace in an unnamed temporary
|
|
|
|
# direct-list-initialization.
|
|
|
|
sp_after_type_brace_init_lst_open = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before close brace in an unnamed temporary
|
|
|
|
# direct-list-initialization.
|
|
|
|
sp_before_type_brace_init_lst_close = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside an unnamed temporary direct-list-initialization.
|
|
|
|
sp_inside_type_brace_init_lst = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside '{' and '}'.
|
|
|
|
sp_inside_braces = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside '{}'.
|
|
|
|
sp_inside_braces_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around trailing return operator '->'.
|
|
|
|
sp_trailing_return = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between return type and function name. A minimum of 1
|
|
|
|
# is forced except for pointer return types.
|
|
|
|
sp_type_func = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between type and open brace of an unnamed temporary
|
|
|
|
# direct-list-initialization.
|
|
|
|
sp_type_brace_init_lst = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between function name and '(' on function declaration.
|
|
|
|
sp_func_proto_paren = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between function name and '()' on function declaration
|
|
|
|
# without parameters.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_func_proto_paren_empty = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between function name and '(' with a typedef specifier.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_func_type_paren = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between alias name and '(' of a non-pointer function type typedef.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_func_def_paren = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between function name and '()' on function definition
|
|
|
|
# without parameters.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_func_def_paren_empty = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space inside empty function '()'.
|
|
|
|
# Overrides sp_after_angle unless use_sp_after_angle_always is set to true.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_inside_fparens = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space inside function '(' and ')'.
|
2020-03-20 06:47:07 -04:00
|
|
|
sp_inside_fparen = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space inside the first parentheses in a function type, as in
|
|
|
|
# 'void (*x)(...)'.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_inside_tparen = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between the ')' and '(' in a function type, as in
|
|
|
|
# 'void (*x)(...)'.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_after_tparen_close = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between ']' and '(' when part of a function call.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_square_fparen = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between ')' and '{' of function.
|
|
|
|
sp_fparen_brace = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between ')' and '{' of s function call in object
|
|
|
|
# initialization.
|
|
|
|
#
|
|
|
|
# Overrides sp_fparen_brace.
|
|
|
|
sp_fparen_brace_initializer = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (Java) Add or remove space between ')' and '{{' of double brace initializer.
|
|
|
|
sp_fparen_dbrace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between function name and '(' on function calls.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_func_call_paren = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between function name and '()' on function calls without
|
|
|
|
# parameters. If set to ignore (the default), sp_func_call_paren is used.
|
2020-06-16 10:34:51 -04:00
|
|
|
sp_func_call_paren_empty = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between the user function name and '(' on function
|
|
|
|
# calls. You need to set a keyword to be a user function in the config file,
|
|
|
|
# like:
|
|
|
|
# set func_call_user tr _ i18n
|
|
|
|
sp_func_call_user_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside user function '(' and ')'.
|
|
|
|
sp_func_call_user_inside_fparen = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between nested parentheses with user functions,
|
|
|
|
# i.e. '((' vs. '( ('.
|
|
|
|
sp_func_call_user_paren_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between a constructor/destructor and the open
|
|
|
|
# parenthesis.
|
|
|
|
sp_func_class_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between a constructor without parameters or destructor
|
|
|
|
# and '()'.
|
|
|
|
sp_func_class_paren_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'return' and '('.
|
|
|
|
sp_return_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'return' and '{'.
|
|
|
|
sp_return_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '__attribute__' and '('.
|
|
|
|
sp_attribute_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'defined' and '(' in '#if defined (FOO)'.
|
2020-03-26 09:35:04 -04:00
|
|
|
sp_defined_paren = remove # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove space between 'throw' and '(' in 'throw (something)'.
|
|
|
|
sp_throw_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'throw' and anything other than '(' as in
|
|
|
|
# '@throw [...];'.
|
|
|
|
sp_after_throw = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'catch' and '(' in 'catch (something) { }'.
|
|
|
|
# If set to ignore, sp_before_sparen is used.
|
|
|
|
sp_catch_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space between '@catch' and '('
|
|
|
|
# in '@catch (something) { }'. If set to ignore, sp_catch_paren is used.
|
|
|
|
sp_oc_catch_paren = ignore # ignore/add/remove/force
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# (OC) Add or remove space before Objective-C protocol list
|
|
|
|
# as in '@protocol Protocol<here><Protocol_A>' or '@interface MyClass : NSObject<here><MyProtocol>'.
|
|
|
|
sp_before_oc_proto_list = ignore # ignore/add/remove/force
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# (OC) Add or remove space between class name and '('
|
|
|
|
# in '@interface className(categoryName)<ProtocolName>:BaseClass'
|
|
|
|
sp_oc_classname_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space between 'version' and '('
|
|
|
|
# in 'version (something) { }'. If set to ignore, sp_before_sparen is used.
|
|
|
|
sp_version_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space between 'scope' and '('
|
|
|
|
# in 'scope (something) { }'. If set to ignore, sp_before_sparen is used.
|
|
|
|
sp_scope_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'super' and '(' in 'super (something)'.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_super_paren = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'this' and '(' in 'this (something)'.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_this_paren = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between a macro name and its definition.
|
|
|
|
sp_macro = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between a macro function ')' and its definition.
|
|
|
|
sp_macro_func = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'else' and '{' if on the same line.
|
|
|
|
sp_else_brace = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '}' and 'else' if on the same line.
|
|
|
|
sp_brace_else = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '}' and the name of a typedef on the same line.
|
|
|
|
sp_brace_typedef = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before the '{' of a 'catch' statement, if the '{' and
|
|
|
|
# 'catch' are on the same line, as in 'catch (decl) <here> {'.
|
|
|
|
sp_catch_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space before the '{' of a '@catch' statement, if the '{'
|
|
|
|
# and '@catch' are on the same line, as in '@catch (decl) <here> {'.
|
|
|
|
# If set to ignore, sp_catch_brace is used.
|
|
|
|
sp_oc_catch_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '}' and 'catch' if on the same line.
|
|
|
|
sp_brace_catch = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space between '}' and '@catch' if on the same line.
|
|
|
|
# If set to ignore, sp_brace_catch is used.
|
|
|
|
sp_oc_brace_catch = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'finally' and '{' if on the same line.
|
|
|
|
sp_finally_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '}' and 'finally' if on the same line.
|
|
|
|
sp_brace_finally = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'try' and '{' if on the same line.
|
|
|
|
sp_try_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between get/set and '{' if on the same line.
|
|
|
|
sp_getset_brace = ignore # ignore/add/remove/force
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Add or remove space between a variable and '{' for C++ uniform
|
|
|
|
# initialization.
|
|
|
|
sp_word_brace_init_lst = ignore # ignore/add/remove/force
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Add or remove space between a variable and '{' for a namespace.
|
|
|
|
#
|
|
|
|
# Default: add
|
|
|
|
sp_word_brace_ns = add # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before the '::' operator.
|
|
|
|
sp_before_dc = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the '::' operator.
|
|
|
|
sp_after_dc = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove around the D named array initializer ':' operator.
|
|
|
|
sp_d_array_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the '!' (not) unary operator.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_not = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the '~' (invert) unary operator.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_inv = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the '&' (address-of) unary operator. This does not
|
|
|
|
# affect the spacing after a '&' that is part of a type.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_addr = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around the '.' or '->' operators.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_member = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the '*' (dereference) unary operator. This does
|
|
|
|
# not affect the spacing after a '*' that is part of a type.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_deref = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after '+' or '-', as in 'x = -5' or 'y = +7'.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_sign = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between '++' and '--' the word to which it is being
|
|
|
|
# applied, as in '(--x)' or 'y++;'.
|
|
|
|
#
|
|
|
|
# Default: remove
|
|
|
|
sp_incdec = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a backslash-newline at the end of a line.
|
|
|
|
#
|
|
|
|
# Default: add
|
|
|
|
sp_before_nl_cont = add # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after the scope '+' or '-', as in '-(void) foo;'
|
|
|
|
# or '+(int) bar;'.
|
|
|
|
sp_after_oc_scope = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after the colon in message specs,
|
|
|
|
# i.e. '-(int) f:(int) x;' vs. '-(int) f: (int) x;'.
|
|
|
|
sp_after_oc_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space before the colon in message specs,
|
|
|
|
# i.e. '-(int) f: (int) x;' vs. '-(int) f : (int) x;'.
|
|
|
|
sp_before_oc_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after the colon in immutable dictionary expression
|
|
|
|
# 'NSDictionary *test = @{@"foo" :@"bar"};'.
|
|
|
|
sp_after_oc_dict_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space before the colon in immutable dictionary expression
|
|
|
|
# 'NSDictionary *test = @{@"foo" :@"bar"};'.
|
|
|
|
sp_before_oc_dict_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after the colon in message specs,
|
|
|
|
# i.e. '[object setValue:1];' vs. '[object setValue: 1];'.
|
|
|
|
sp_after_send_oc_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space before the colon in message specs,
|
|
|
|
# i.e. '[object setValue:1];' vs. '[object setValue :1];'.
|
|
|
|
sp_before_send_oc_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after the (type) in message specs,
|
|
|
|
# i.e. '-(int)f: (int) x;' vs. '-(int)f: (int)x;'.
|
|
|
|
sp_after_oc_type = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after the first (type) in message specs,
|
|
|
|
# i.e. '-(int) f:(int)x;' vs. '-(int)f:(int)x;'.
|
|
|
|
sp_after_oc_return_type = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space between '@selector' and '(',
|
|
|
|
# i.e. '@selector(msgName)' vs. '@selector (msgName)'.
|
|
|
|
# Also applies to '@protocol()' constructs.
|
|
|
|
sp_after_oc_at_sel = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space between '@selector(x)' and the following word,
|
|
|
|
# i.e. '@selector(foo) a:' vs. '@selector(foo)a:'.
|
|
|
|
sp_after_oc_at_sel_parens = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space inside '@selector' parentheses,
|
|
|
|
# i.e. '@selector(foo)' vs. '@selector( foo )'.
|
|
|
|
# Also applies to '@protocol()' constructs.
|
|
|
|
sp_inside_oc_at_sel_parens = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space before a block pointer caret,
|
|
|
|
# i.e. '^int (int arg){...}' vs. ' ^int (int arg){...}'.
|
|
|
|
sp_before_oc_block_caret = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after a block pointer caret,
|
|
|
|
# i.e. '^int (int arg){...}' vs. '^ int (int arg){...}'.
|
|
|
|
sp_after_oc_block_caret = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space between the receiver and selector in a message,
|
|
|
|
# as in '[receiver selector ...]'.
|
|
|
|
sp_after_oc_msg_receiver = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space after '@property'.
|
|
|
|
sp_after_oc_property = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove space between '@synchronized' and the open parenthesis,
|
|
|
|
# i.e. '@synchronized(foo)' vs. '@synchronized (foo)'.
|
|
|
|
sp_after_oc_synchronized = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around the ':' in 'b ? t : f'.
|
|
|
|
sp_cond_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before the ':' in 'b ? t : f'.
|
|
|
|
#
|
|
|
|
# Overrides sp_cond_colon.
|
|
|
|
sp_cond_colon_before = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the ':' in 'b ? t : f'.
|
|
|
|
#
|
|
|
|
# Overrides sp_cond_colon.
|
|
|
|
sp_cond_colon_after = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space around the '?' in 'b ? t : f'.
|
|
|
|
sp_cond_question = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before the '?' in 'b ? t : f'.
|
|
|
|
#
|
|
|
|
# Overrides sp_cond_question.
|
|
|
|
sp_cond_question_before = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the '?' in 'b ? t : f'.
|
|
|
|
#
|
|
|
|
# Overrides sp_cond_question.
|
|
|
|
sp_cond_question_after = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# In the abbreviated ternary form '(a ?: b)', add or remove space between '?'
|
|
|
|
# and ':'.
|
|
|
|
#
|
|
|
|
# Overrides all other sp_cond_* options.
|
|
|
|
sp_cond_ternary_short = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Fix the spacing between 'case' and the label. Only 'ignore' and 'force' make
|
|
|
|
# sense here.
|
|
|
|
sp_case_label = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space around the D '..' operator.
|
|
|
|
sp_range = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after ':' in a Java/C++11 range-based 'for',
|
|
|
|
# as in 'for (Type var : expr)'.
|
|
|
|
sp_after_for_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before ':' in a Java/C++11 range-based 'for',
|
|
|
|
# as in 'for (Type var : expr)'.
|
|
|
|
sp_before_for_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove space between 'extern' and '(' as in 'extern (C)'.
|
|
|
|
sp_extern_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the opening of a C++ comment,
|
|
|
|
# i.e. '// A' vs. '//A'.
|
2020-04-16 03:13:57 -04:00
|
|
|
sp_cmt_cpp_start = add # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# If true, space is added with sp_cmt_cpp_start will be added after doxygen
|
|
|
|
# sequences like '///', '///<', '//!' and '//!<'.
|
|
|
|
sp_cmt_cpp_doxygen = false # true/false
|
|
|
|
|
|
|
|
# If true, space is added with sp_cmt_cpp_start will be added after Qt
|
|
|
|
# translator or meta-data comments like '//:', '//=', and '//~'.
|
|
|
|
sp_cmt_cpp_qttr = false # true/false
|
|
|
|
|
|
|
|
# Add or remove space between #else or #endif and a trailing comment.
|
|
|
|
sp_endif_cmt = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after 'new', 'delete' and 'delete[]'.
|
|
|
|
sp_after_new = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between 'new' and '(' in 'new()'.
|
|
|
|
sp_between_new_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space between ')' and type in 'new(foo) BAR'.
|
|
|
|
sp_after_newop_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space inside parenthesis of the new operator
|
|
|
|
# as in 'new(foo) BAR'.
|
|
|
|
sp_inside_newop_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after the open parenthesis of the new operator,
|
|
|
|
# as in 'new(foo) BAR'.
|
|
|
|
#
|
|
|
|
# Overrides sp_inside_newop_paren.
|
|
|
|
sp_inside_newop_paren_open = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before the close parenthesis of the new operator,
|
|
|
|
# as in 'new(foo) BAR'.
|
|
|
|
#
|
|
|
|
# Overrides sp_inside_newop_paren.
|
|
|
|
sp_inside_newop_paren_close = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space before a trailing or embedded comment.
|
|
|
|
sp_before_tr_emb_cmt = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Number of spaces before a trailing or embedded comment.
|
|
|
|
sp_num_before_tr_emb_cmt = 0 # unsigned number
|
|
|
|
|
|
|
|
# (Java) Add or remove space between an annotation and the open parenthesis.
|
|
|
|
sp_annotation_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# If true, vbrace tokens are dropped to the previous token and skipped.
|
|
|
|
sp_skip_vbrace_tokens = false # true/false
|
|
|
|
|
|
|
|
# Add or remove space after 'noexcept'.
|
|
|
|
sp_after_noexcept = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove space after '_'.
|
|
|
|
sp_vala_after_translation = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# If true, a <TAB> is inserted after #define.
|
|
|
|
force_tab_after_define = false # true/false
|
|
|
|
|
|
|
|
#
|
|
|
|
# Indenting options
|
|
|
|
#
|
|
|
|
|
|
|
|
# The number of columns to indent per level. Usually 2, 3, 4, or 8.
|
|
|
|
#
|
|
|
|
# Default: 8
|
|
|
|
indent_columns = 4 # unsigned number
|
|
|
|
|
|
|
|
# The continuation indent. If non-zero, this overrides the indent of '(', '['
|
|
|
|
# and '=' continuation indents. Negative values are OK; negative value is
|
|
|
|
# absolute and not increased for each '(' or '[' level.
|
|
|
|
#
|
|
|
|
# For FreeBSD, this is set to 4.
|
|
|
|
indent_continue = 0 # number
|
|
|
|
|
|
|
|
# The continuation indent, only for class header line(s). If non-zero, this
|
|
|
|
# overrides the indent of 'class' continuation indents.
|
|
|
|
indent_continue_class_head = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to indent empty lines (i.e. lines which contain only spaces before
|
|
|
|
# the newline character).
|
|
|
|
indent_single_newlines = false # true/false
|
|
|
|
|
|
|
|
# The continuation indent for func_*_param if they are true. If non-zero, this
|
|
|
|
# overrides the indent.
|
|
|
|
indent_param = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to use tabs when indenting code.
|
|
|
|
#
|
|
|
|
# 0: Spaces only
|
|
|
|
# 1: Indent with tabs to brace level, align with spaces (default)
|
|
|
|
# 2: Indent and align with tabs, using spaces when not on a tabstop
|
|
|
|
#
|
|
|
|
# Default: 1
|
|
|
|
indent_with_tabs = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to indent comments that are not at a brace level with tabs on a
|
|
|
|
# tabstop. Requires indent_with_tabs=2. If false, will use spaces.
|
|
|
|
indent_cmt_with_tabs = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent strings broken by '\' so that they line up.
|
|
|
|
indent_align_string = false # true/false
|
|
|
|
|
|
|
|
# The number of spaces to indent multi-line XML strings.
|
|
|
|
# Requires indent_align_string=true.
|
|
|
|
indent_xml_string = 0 # unsigned number
|
|
|
|
|
|
|
|
# Spaces to indent '{' from level.
|
|
|
|
indent_brace = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether braces are indented to the body level.
|
|
|
|
indent_braces = false # true/false
|
|
|
|
|
|
|
|
# Whether to disable indenting function braces if indent_braces=true.
|
|
|
|
indent_braces_no_func = false # true/false
|
|
|
|
|
|
|
|
# Whether to disable indenting class braces if indent_braces=true.
|
|
|
|
indent_braces_no_class = false # true/false
|
|
|
|
|
|
|
|
# Whether to disable indenting struct braces if indent_braces=true.
|
|
|
|
indent_braces_no_struct = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent based on the size of the brace parent,
|
|
|
|
# i.e. 'if' => 3 spaces, 'for' => 4 spaces, etc.
|
|
|
|
indent_brace_parent = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent based on the open parenthesis instead of the open brace
|
|
|
|
# in '({\n'.
|
|
|
|
indent_paren_open_brace = false # true/false
|
|
|
|
|
|
|
|
# (C#) Whether to indent the brace of a C# delegate by another level.
|
|
|
|
indent_cs_delegate_brace = false # true/false
|
|
|
|
|
|
|
|
# (C#) Whether to indent a C# delegate (to handle delegates with no brace) by
|
|
|
|
# another level.
|
|
|
|
indent_cs_delegate_body = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent the body of a 'namespace'.
|
|
|
|
indent_namespace = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent only the first namespace, and not any nested namespaces.
|
|
|
|
# Requires indent_namespace=true.
|
|
|
|
indent_namespace_single_indent = false # true/false
|
|
|
|
|
|
|
|
# The number of spaces to indent a namespace block.
|
|
|
|
# If set to zero, use the value indent_columns
|
|
|
|
indent_namespace_level = 0 # unsigned number
|
|
|
|
|
|
|
|
# If the body of the namespace is longer than this number, it won't be
|
|
|
|
# indented. Requires indent_namespace=true. 0 means no limit.
|
|
|
|
indent_namespace_limit = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether the 'extern "C"' body is indented.
|
|
|
|
indent_extern = false # true/false
|
|
|
|
|
|
|
|
# Whether the 'class' body is indented.
|
|
|
|
indent_class = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent the stuff after a leading base class colon.
|
|
|
|
indent_class_colon = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent based on a class colon instead of the stuff after the
|
|
|
|
# colon. Requires indent_class_colon=true.
|
|
|
|
indent_class_on_colon = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent the stuff after a leading class initializer colon.
|
|
|
|
indent_constr_colon = false # true/false
|
|
|
|
|
|
|
|
# Virtual indent from the ':' for member initializers.
|
|
|
|
#
|
|
|
|
# Default: 2
|
|
|
|
indent_ctor_init_leading = 2 # unsigned number
|
|
|
|
|
|
|
|
# Additional indent for constructor initializer list.
|
|
|
|
# Negative values decrease indent down to the first column.
|
|
|
|
indent_ctor_init = 0 # number
|
|
|
|
|
|
|
|
# Whether to indent 'if' following 'else' as a new block under the 'else'.
|
|
|
|
# If false, 'else\nif' is treated as 'else if' for indenting purposes.
|
|
|
|
indent_else_if = false # true/false
|
|
|
|
|
|
|
|
# Amount to indent variable declarations after a open brace.
|
|
|
|
#
|
|
|
|
# <0: Relative
|
|
|
|
# >=0: Absolute
|
|
|
|
indent_var_def_blk = 0 # number
|
|
|
|
|
|
|
|
# Whether to indent continued variable declarations instead of aligning.
|
|
|
|
indent_var_def_cont = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent continued shift expressions ('<<' and '>>') instead of
|
|
|
|
# aligning. Set align_left_shift=false when enabling this.
|
|
|
|
indent_shift = false # true/false
|
|
|
|
|
|
|
|
# Whether to force indentation of function definitions to start in column 1.
|
|
|
|
indent_func_def_force_col1 = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent continued function call parameters one indent level,
|
|
|
|
# rather than aligning parameters under the open parenthesis.
|
|
|
|
indent_func_call_param = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent continued function definition parameters one indent level,
|
|
|
|
# rather than aligning parameters under the open parenthesis.
|
|
|
|
indent_func_def_param = true # true/false
|
|
|
|
|
|
|
|
# for function definitions, only if indent_func_def_param is false
|
|
|
|
# Allows to align params when appropriate and indent them when not
|
|
|
|
# behave as if it was true if paren position is more than this value
|
|
|
|
# if paren position is more than the option value
|
|
|
|
indent_func_def_param_paren_pos_threshold = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to indent continued function call prototype one indent level,
|
|
|
|
# rather than aligning parameters under the open parenthesis.
|
|
|
|
indent_func_proto_param = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent continued function call declaration one indent level,
|
|
|
|
# rather than aligning parameters under the open parenthesis.
|
|
|
|
indent_func_class_param = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent continued class variable constructors one indent level,
|
|
|
|
# rather than aligning parameters under the open parenthesis.
|
|
|
|
indent_func_ctor_var_param = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent continued template parameter list one indent level,
|
|
|
|
# rather than aligning parameters under the open parenthesis.
|
|
|
|
indent_template_param = true # true/false
|
|
|
|
|
|
|
|
# Double the indent for indent_func_xxx_param options.
|
|
|
|
# Use both values of the options indent_columns and indent_param.
|
|
|
|
indent_func_param_double = false # true/false
|
|
|
|
|
|
|
|
# Indentation column for standalone 'const' qualifier on a function
|
|
|
|
# prototype.
|
|
|
|
indent_func_const = 0 # unsigned number
|
|
|
|
|
|
|
|
# Indentation column for standalone 'throw' qualifier on a function
|
|
|
|
# prototype.
|
|
|
|
indent_func_throw = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to indent within a macro followed by a brace on the same line
|
|
|
|
# This allows reducing the indent in macros that have (for example)
|
|
|
|
# `do { ... } while (0)` blocks bracketing them.
|
|
|
|
#
|
|
|
|
# true: add an indent for the brace on the same line as the macro
|
|
|
|
# false: do not add an indent for the brace on the same line as the macro
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_macro_brace = true # true/false
|
|
|
|
|
|
|
|
# The number of spaces to indent a continued '->' or '.'.
|
|
|
|
# Usually set to 0, 1, or indent_columns.
|
|
|
|
indent_member = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether lines broken at '.' or '->' should be indented by a single indent.
|
|
|
|
# The indent_member option will not be effective if this is set to true.
|
|
|
|
indent_member_single = false # true/false
|
|
|
|
|
|
|
|
# Spaces to indent single line ('//') comments on lines before code.
|
|
|
|
indent_sing_line_comments = 0 # unsigned number
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# When opening a paren for a control statement (if, for, while, etc), increase
|
|
|
|
# the indent level by this value. Negative values decrease the indent level.
|
|
|
|
indent_sparen_extra = 0 # number
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Whether to indent trailing single line ('//') comments relative to the code
|
|
|
|
# instead of trying to keep the same absolute column.
|
|
|
|
indent_relative_single_line_comments = false # true/false
|
|
|
|
|
|
|
|
# Spaces to indent 'case' from 'switch'. Usually 0 or indent_columns.
|
|
|
|
indent_switch_case = indent_columns # unsigned number
|
|
|
|
|
|
|
|
# indent 'break' with 'case' from 'switch'.
|
|
|
|
indent_switch_break_with_case = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent preprocessor statements inside of switch statements.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_switch_pp = true # true/false
|
|
|
|
|
|
|
|
# Spaces to shift the 'case' line, without affecting any other lines.
|
|
|
|
# Usually 0.
|
|
|
|
indent_case_shift = 0 # unsigned number
|
|
|
|
|
|
|
|
# Spaces to indent '{' from 'case'. By default, the brace will appear under
|
|
|
|
# the 'c' in case. Usually set to 0 or indent_columns. Negative values are OK.
|
|
|
|
indent_case_brace = 0 # number
|
|
|
|
|
|
|
|
# Whether to indent comments found in first column.
|
|
|
|
indent_col1_comment = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent multi string literal in first column.
|
|
|
|
indent_col1_multi_string_literal = false # true/false
|
|
|
|
|
|
|
|
# How to indent goto labels.
|
|
|
|
#
|
|
|
|
# >0: Absolute column where 1 is the leftmost column
|
|
|
|
# <=0: Subtract from brace indent
|
|
|
|
#
|
|
|
|
# Default: 1
|
|
|
|
indent_label = -indent_columns # number
|
|
|
|
|
|
|
|
# How to indent access specifiers that are followed by a
|
|
|
|
# colon.
|
|
|
|
#
|
|
|
|
# >0: Absolute column where 1 is the leftmost column
|
|
|
|
# <=0: Subtract from brace indent
|
|
|
|
#
|
|
|
|
# Default: 1
|
|
|
|
indent_access_spec = 1 # number
|
|
|
|
|
|
|
|
# Whether to indent the code after an access specifier by one level.
|
|
|
|
# If true, this option forces 'indent_access_spec=0'.
|
|
|
|
indent_access_spec_body = false # true/false
|
|
|
|
|
|
|
|
# If an open parenthesis is followed by a newline, whether to indent the next
|
|
|
|
# line so that it lines up after the open parenthesis (not recommended).
|
|
|
|
indent_paren_nl = false # true/false
|
|
|
|
|
|
|
|
# How to indent a close parenthesis after a newline.
|
|
|
|
#
|
|
|
|
# 0: Indent to body level (default)
|
|
|
|
# 1: Align under the open parenthesis
|
|
|
|
# 2: Indent to the brace level
|
|
|
|
indent_paren_close = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to indent the open parenthesis of a function definition,
|
|
|
|
# if the parenthesis is on its own line.
|
|
|
|
indent_paren_after_func_def = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent the open parenthesis of a function declaration,
|
|
|
|
# if the parenthesis is on its own line.
|
|
|
|
indent_paren_after_func_decl = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent the open parenthesis of a function call,
|
|
|
|
# if the parenthesis is on its own line.
|
|
|
|
indent_paren_after_func_call = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent a comma when inside a parenthesis.
|
|
|
|
# If true, aligns under the open parenthesis.
|
|
|
|
indent_comma_paren = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent a Boolean operator when inside a parenthesis.
|
|
|
|
# If true, aligns under the open parenthesis.
|
|
|
|
indent_bool_paren = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent a semicolon when inside a for parenthesis.
|
|
|
|
# If true, aligns under the open for parenthesis.
|
|
|
|
indent_semicolon_for_paren = false # true/false
|
|
|
|
|
|
|
|
# Whether to align the first expression to following ones
|
|
|
|
# if indent_bool_paren=true.
|
|
|
|
indent_first_bool_expr = false # true/false
|
|
|
|
|
|
|
|
# Whether to align the first expression to following ones
|
|
|
|
# if indent_semicolon_for_paren=true.
|
|
|
|
indent_first_for_expr = false # true/false
|
|
|
|
|
|
|
|
# If an open square is followed by a newline, whether to indent the next line
|
|
|
|
# so that it lines up after the open square (not recommended).
|
|
|
|
indent_square_nl = false # true/false
|
|
|
|
|
|
|
|
# (ESQL/C) Whether to preserve the relative indent of 'EXEC SQL' bodies.
|
|
|
|
indent_preserve_sql = false # true/false
|
|
|
|
|
|
|
|
# Whether to align continued statements at the '='. If false or if the '=' is
|
|
|
|
# followed by a newline, the next line is indent one tab.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_align_assign = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# If true, the indentation of the chunks after a '=' sequence will be set at
|
|
|
|
# LHS token indentation column before '='.
|
|
|
|
indent_off_after_assign = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Whether to align continued statements at the '('. If false or the '(' is
|
|
|
|
# followed by a newline, the next line indent is one tab.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_align_paren = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# (OC) Whether to indent Objective-C code inside message selectors.
|
|
|
|
indent_oc_inside_msg_sel = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# (OC) Whether to indent Objective-C blocks at brace level instead of usual
|
|
|
|
# rules.
|
|
|
|
indent_oc_block = false # true/false
|
|
|
|
|
|
|
|
# (OC) Indent for Objective-C blocks in a message relative to the parameter
|
|
|
|
# name.
|
|
|
|
#
|
|
|
|
# =0: Use indent_oc_block rules
|
|
|
|
# >0: Use specified number of spaces to indent
|
|
|
|
indent_oc_block_msg = 0 # unsigned number
|
|
|
|
|
|
|
|
# (OC) Minimum indent for subsequent parameters
|
|
|
|
indent_oc_msg_colon = 0 # unsigned number
|
|
|
|
|
|
|
|
# (OC) Whether to prioritize aligning with initial colon (and stripping spaces
|
|
|
|
# from lines, if necessary).
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_oc_msg_prioritize_first_colon = true # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to indent blocks the way that Xcode does by default
|
|
|
|
# (from the keyword if the parameter is on its own line; otherwise, from the
|
|
|
|
# previous indentation level). Requires indent_oc_block_msg=true.
|
|
|
|
indent_oc_block_msg_xcode_style = false # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to indent blocks from where the brace is, relative to a
|
|
|
|
# message keyword. Requires indent_oc_block_msg=true.
|
|
|
|
indent_oc_block_msg_from_keyword = false # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to indent blocks from where the brace is, relative to a message
|
|
|
|
# colon. Requires indent_oc_block_msg=true.
|
|
|
|
indent_oc_block_msg_from_colon = false # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to indent blocks from where the block caret is.
|
|
|
|
# Requires indent_oc_block_msg=true.
|
|
|
|
indent_oc_block_msg_from_caret = false # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to indent blocks from where the brace caret is.
|
|
|
|
# Requires indent_oc_block_msg=true.
|
|
|
|
indent_oc_block_msg_from_brace = false # true/false
|
|
|
|
|
|
|
|
# When indenting after virtual brace open and newline add further spaces to
|
|
|
|
# reach this minimum indent.
|
|
|
|
indent_min_vbrace_open = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to add further spaces after regular indent to reach next tabstop
|
|
|
|
# when identing after virtual brace open and newline.
|
|
|
|
indent_vbrace_open_on_tabstop = false # true/false
|
|
|
|
|
|
|
|
# How to indent after a brace followed by another token (not a newline).
|
|
|
|
# true: indent all contained lines to match the token
|
|
|
|
# false: indent all contained lines to match the brace
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_token_after_brace = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent the body of a C++11 lambda.
|
|
|
|
indent_cpp_lambda_body = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# How to indent compound literals that are being returned.
|
|
|
|
# true: add both the indent from return & the compound literal open brace (ie:
|
|
|
|
# 2 indent levels)
|
|
|
|
# false: only indent 1 level, don't add the indent for the open brace, only add
|
|
|
|
# the indent for the return.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_compound_literal_return = true # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# (C#) Whether to indent a 'using' block if no braces are used.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
indent_using_block = true # true/false
|
|
|
|
|
|
|
|
# How to indent the continuation of ternary operator.
|
|
|
|
#
|
|
|
|
# 0: Off (default)
|
|
|
|
# 1: When the `if_false` is a continuation, indent it under `if_false`
|
|
|
|
# 2: When the `:` is a continuation, indent it under `?`
|
|
|
|
indent_ternary_operator = 0 # unsigned number
|
|
|
|
|
2023-03-18 11:17:02 -04:00
|
|
|
# Whether to indent the statements inside ternary operator.
|
2020-06-14 12:02:19 -04:00
|
|
|
indent_inside_ternary_operator = false # true/false
|
|
|
|
|
|
|
|
# If true, the indentation of the chunks after a `return` sequence will be set at return indentation column.
|
|
|
|
indent_off_after_return = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# If true, the indentation of the chunks after a `return new` sequence will be set at return indentation column.
|
|
|
|
indent_off_after_return_new = false # true/false
|
|
|
|
|
|
|
|
# If true, the tokens after return are indented with regular single indentation. By default (false) the indentation is after the return token.
|
|
|
|
indent_single_after_return = false # true/false
|
|
|
|
|
|
|
|
# Whether to ignore indent and alignment for 'asm' blocks (i.e. assume they
|
|
|
|
# have their own indentation).
|
|
|
|
indent_ignore_asm_block = false # true/false
|
|
|
|
|
|
|
|
#
|
|
|
|
# Newline adding and removing options
|
|
|
|
#
|
|
|
|
|
|
|
|
# Whether to collapse empty blocks between '{' and '}'.
|
|
|
|
nl_collapse_empty_body = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line braced assignments, as in 'foo_t f = { 1, 2 };'.
|
|
|
|
nl_assign_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line braced statements inside a 'class xx { }' body.
|
|
|
|
nl_class_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line enums, as in 'enum foo { BAR = 15 };'
|
|
|
|
nl_enum_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line get or set functions.
|
|
|
|
nl_getset_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# (C#) Don't split one-line property get or set functions.
|
|
|
|
nl_cs_property_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line function definitions, as in 'int foo() { return 0; }'.
|
2020-06-14 12:02:19 -04:00
|
|
|
# might modify nl_func_type_name
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
nl_func_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line C++11 lambdas, as in '[]() { return 0; }'.
|
|
|
|
nl_cpp_lambda_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line if/else statements, as in 'if(...) b++;'.
|
|
|
|
nl_if_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line while statements, as in 'while(...) b++;'.
|
|
|
|
nl_while_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# Don't split one-line for statements, as in 'for(...) b++;'.
|
|
|
|
nl_for_leave_one_liners = false # true/false
|
|
|
|
|
|
|
|
# (OC) Don't split one-line Objective-C messages.
|
|
|
|
nl_oc_msg_leave_one_liner = false # true/false
|
|
|
|
|
|
|
|
# (OC) Add or remove newline between method declaration and '{'.
|
|
|
|
nl_oc_mdef_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove newline between Objective-C block signature and '{'.
|
|
|
|
nl_oc_block_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove blank line before '@interface' statement.
|
|
|
|
nl_oc_before_interface = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove blank line before '@implementation' statement.
|
|
|
|
nl_oc_before_implementation = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove blank line before '@end' statement.
|
|
|
|
nl_oc_before_end = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove newline between '@interface' and '{'.
|
|
|
|
nl_oc_interface_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove newline between '@implementation' and '{'.
|
|
|
|
nl_oc_implementation_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newlines at the start of the file.
|
|
|
|
nl_start_of_file = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# The minimum number of newlines at the start of the file (only used if
|
|
|
|
# nl_start_of_file is 'add' or 'force').
|
|
|
|
nl_start_of_file_min = 0 # unsigned number
|
|
|
|
|
|
|
|
# Add or remove newline at the end of the file.
|
2021-08-28 11:58:38 -04:00
|
|
|
nl_end_of_file = force # ignore/add/remove/force
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# The minimum number of newlines at the end of the file (only used if
|
|
|
|
# nl_end_of_file is 'add' or 'force').
|
2021-08-28 11:58:38 -04:00
|
|
|
nl_end_of_file_min = 1 # unsigned number
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
|
|
|
|
# Add or remove newline between '=' and '{'.
|
|
|
|
nl_assign_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove newline between '=' and '['.
|
|
|
|
nl_assign_square = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '[]' and '{'.
|
|
|
|
nl_tsquare_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove newline after '= ['. Will also affect the newline before
|
|
|
|
# the ']'.
|
|
|
|
nl_after_square_assign = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between a function call's ')' and '{', as in
|
|
|
|
# 'list_for_each(item, &list) { }'.
|
|
|
|
nl_fcall_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'enum' and '{'.
|
|
|
|
nl_enum_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'enum' and 'class'.
|
|
|
|
nl_enum_class = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'enum class' and the identifier.
|
|
|
|
nl_enum_class_identifier = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'enum class' type and ':'.
|
|
|
|
nl_enum_identifier_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'enum class identifier :' and type.
|
|
|
|
nl_enum_colon_type = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'struct and '{'.
|
|
|
|
nl_struct_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'union' and '{'.
|
|
|
|
nl_union_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'if' and '{'.
|
|
|
|
nl_if_brace = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '}' and 'else'.
|
|
|
|
nl_brace_else = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'else if' and '{'. If set to ignore,
|
|
|
|
# nl_if_brace is used instead.
|
|
|
|
nl_elseif_brace = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'else' and '{'.
|
|
|
|
nl_else_brace = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'else' and 'if'.
|
|
|
|
nl_else_if = ignore # ignore/add/remove/force
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Add or remove newline before '{' opening brace
|
|
|
|
nl_before_opening_brace_func_class_def = ignore # ignore/add/remove/force
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Add or remove newline before 'if'/'else if' closing parenthesis.
|
|
|
|
nl_before_if_closing_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '}' and 'finally'.
|
|
|
|
nl_brace_finally = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'finally' and '{'.
|
|
|
|
nl_finally_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'try' and '{'.
|
|
|
|
nl_try_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between get/set and '{'.
|
|
|
|
nl_getset_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'for' and '{'.
|
|
|
|
nl_for_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline before the '{' of a 'catch' statement, as in
|
|
|
|
# 'catch (decl) <here> {'.
|
|
|
|
nl_catch_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove newline before the '{' of a '@catch' statement, as in
|
|
|
|
# '@catch (decl) <here> {'. If set to ignore, nl_catch_brace is used.
|
|
|
|
nl_oc_catch_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '}' and 'catch'.
|
|
|
|
nl_brace_catch = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Add or remove newline between '}' and '@catch'. If set to ignore,
|
|
|
|
# nl_brace_catch is used.
|
|
|
|
nl_oc_brace_catch = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '}' and ']'.
|
|
|
|
nl_brace_square = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '}' and ')' in a function invocation.
|
|
|
|
nl_brace_fparen = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'while' and '{'.
|
|
|
|
nl_while_brace = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove newline between 'scope (x)' and '{'.
|
|
|
|
nl_scope_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove newline between 'unittest' and '{'.
|
|
|
|
nl_unittest_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (D) Add or remove newline between 'version (x)' and '{'.
|
|
|
|
nl_version_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (C#) Add or remove newline between 'using' and '{'.
|
|
|
|
nl_using_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between two open or close braces. Due to general
|
|
|
|
# newline/brace handling, REMOVE may not work.
|
|
|
|
nl_brace_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'do' and '{'.
|
|
|
|
nl_do_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '}' and 'while' of 'do' statement.
|
|
|
|
nl_brace_while = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'switch' and '{'.
|
|
|
|
nl_switch_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'synchronized' and '{'.
|
|
|
|
nl_synchronized_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add a newline between ')' and '{' if the ')' is on a different line than the
|
|
|
|
# if/for/etc.
|
|
|
|
#
|
|
|
|
# Overrides nl_for_brace, nl_if_brace, nl_switch_brace, nl_while_switch and
|
|
|
|
# nl_catch_brace.
|
|
|
|
nl_multi_line_cond = false # true/false
|
|
|
|
|
|
|
|
# Add a newline after '(' if an if/for/while/switch condition spans multiple
|
|
|
|
# lines
|
|
|
|
nl_multi_line_sparen_open = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add a newline before ')' if an if/for/while/switch condition spans multiple
|
|
|
|
# lines. Overrides nl_before_if_closing_paren if both are specified.
|
|
|
|
nl_multi_line_sparen_close = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Force a newline in a define after the macro name for multi-line defines.
|
|
|
|
nl_multi_line_define = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline before 'case', and a blank line before a 'case'
|
|
|
|
# statement that follows a ';' or '}'.
|
|
|
|
nl_before_case = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after a 'case' statement.
|
|
|
|
nl_after_case = true # true/false
|
|
|
|
|
|
|
|
# Add or remove newline between a case ':' and '{'.
|
|
|
|
#
|
|
|
|
# Overrides nl_after_case.
|
|
|
|
nl_case_colon_brace = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between ')' and 'throw'.
|
|
|
|
nl_before_throw = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'namespace' and '{'.
|
|
|
|
nl_namespace_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template class.
|
|
|
|
nl_template_class = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template class declaration.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_class.
|
|
|
|
nl_template_class_decl = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<>' of a specialized class declaration.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_class_decl.
|
|
|
|
nl_template_class_decl_special = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template class definition.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_class.
|
|
|
|
nl_template_class_def = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<>' of a specialized class definition.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_class_def.
|
|
|
|
nl_template_class_def_special = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template function.
|
|
|
|
nl_template_func = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template function
|
|
|
|
# declaration.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_func.
|
|
|
|
nl_template_func_decl = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<>' of a specialized function
|
|
|
|
# declaration.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_func_decl.
|
|
|
|
nl_template_func_decl_special = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template function
|
|
|
|
# definition.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_func.
|
|
|
|
nl_template_func_def = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<>' of a specialized function
|
|
|
|
# definition.
|
|
|
|
#
|
|
|
|
# Overrides nl_template_func_def.
|
|
|
|
nl_template_func_def_special = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after 'template<...>' of a template variable.
|
|
|
|
nl_template_var = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'template<...>' and 'using' of a templated
|
|
|
|
# type alias.
|
|
|
|
nl_template_using = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'class' and '{'.
|
|
|
|
nl_class_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline before or after (depending on pos_class_comma,
|
|
|
|
# may not be IGNORE) each',' in the base class list.
|
|
|
|
nl_class_init_args = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after each ',' in the constructor member
|
|
|
|
# initialization. Related to nl_constr_colon, pos_constr_colon and
|
|
|
|
# pos_constr_comma.
|
|
|
|
nl_constr_init_args = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline before first element, after comma, and after last
|
|
|
|
# element, in 'enum'.
|
|
|
|
nl_enum_own_lines = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between return type and function name in a function
|
|
|
|
# definition.
|
|
|
|
# might be modified by nl_func_leave_one_liners
|
|
|
|
nl_func_type_name = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between return type and function name inside a class
|
|
|
|
# definition. If set to ignore, nl_func_type_name or nl_func_proto_type_name
|
|
|
|
# is used instead.
|
|
|
|
nl_func_type_name_class = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between class specification and '::'
|
|
|
|
# in 'void A::f() { }'. Only appears in separate member implementation (does
|
|
|
|
# not appear with in-line implementation).
|
|
|
|
nl_func_class_scope = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between function scope and name, as in
|
|
|
|
# 'void A :: <here> f() { }'.
|
|
|
|
nl_func_scope_name = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between return type and function name in a prototype.
|
|
|
|
nl_func_proto_type_name = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between a function name and the opening '(' in the
|
|
|
|
# declaration.
|
|
|
|
nl_func_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_paren for functions with no parameters.
|
|
|
|
nl_func_paren_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between a function name and the opening '(' in the
|
|
|
|
# definition.
|
|
|
|
nl_func_def_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_def_paren for functions with no parameters.
|
|
|
|
nl_func_def_paren_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between a function name and the opening '(' in the
|
|
|
|
# call.
|
|
|
|
nl_func_call_paren = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_call_paren for functions with no parameters.
|
|
|
|
nl_func_call_paren_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after '(' in a function declaration.
|
|
|
|
nl_func_decl_start = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after '(' in a function definition.
|
|
|
|
nl_func_def_start = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_decl_start when there is only one parameter.
|
|
|
|
nl_func_decl_start_single = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_def_start when there is only one parameter.
|
|
|
|
nl_func_def_start_single = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline after '(' in a function declaration if '(' and ')'
|
|
|
|
# are in different lines. If false, nl_func_decl_start is used instead.
|
|
|
|
nl_func_decl_start_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after '(' in a function definition if '(' and ')'
|
|
|
|
# are in different lines. If false, nl_func_def_start is used instead.
|
|
|
|
nl_func_def_start_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Add or remove newline after each ',' in a function declaration.
|
|
|
|
nl_func_decl_args = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline after each ',' in a function definition.
|
|
|
|
nl_func_def_args = ignore # ignore/add/remove/force
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Add or remove newline after each ',' in a function call.
|
|
|
|
nl_func_call_args = ignore # ignore/add/remove/force
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Whether to add a newline after each ',' in a function declaration if '('
|
|
|
|
# and ')' are in different lines. If false, nl_func_decl_args is used instead.
|
|
|
|
nl_func_decl_args_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after each ',' in a function definition if '('
|
|
|
|
# and ')' are in different lines. If false, nl_func_def_args is used instead.
|
|
|
|
nl_func_def_args_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Add or remove newline before the ')' in a function declaration.
|
|
|
|
nl_func_decl_end = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline before the ')' in a function definition.
|
|
|
|
nl_func_def_end = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_decl_end when there is only one parameter.
|
|
|
|
nl_func_decl_end_single = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Overrides nl_func_def_end when there is only one parameter.
|
|
|
|
nl_func_def_end_single = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline before ')' in a function declaration if '(' and ')'
|
|
|
|
# are in different lines. If false, nl_func_decl_end is used instead.
|
|
|
|
nl_func_decl_end_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline before ')' in a function definition if '(' and ')'
|
|
|
|
# are in different lines. If false, nl_func_def_end is used instead.
|
|
|
|
nl_func_def_end_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Add or remove newline between '()' in a function declaration.
|
|
|
|
nl_func_decl_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '()' in a function definition.
|
|
|
|
nl_func_def_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between '()' in a function call.
|
|
|
|
nl_func_call_empty = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline after '(' in a function call,
|
|
|
|
# has preference over nl_func_call_start_multi_line.
|
|
|
|
nl_func_call_start = ignore # ignore/add/remove/force
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Whether to add a newline before ')' in a function call.
|
|
|
|
nl_func_call_end = ignore # ignore/add/remove/force
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Whether to add a newline after '(' in a function call if '(' and ')' are in
|
|
|
|
# different lines.
|
|
|
|
nl_func_call_start_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after each ',' in a function call if '(' and ')'
|
|
|
|
# are in different lines.
|
|
|
|
nl_func_call_args_multi_line = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline before ')' in a function call if '(' and ')' are in
|
|
|
|
# different lines.
|
|
|
|
nl_func_call_end_multi_line = false # true/false
|
|
|
|
|
2023-03-18 11:17:02 -04:00
|
|
|
# Whether to respect nl_func_call_XXX option in case of closure args.
|
2020-06-14 12:02:19 -04:00
|
|
|
nl_func_call_args_multi_line_ignore_closures = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Whether to add a newline after '<' of a template parameter list.
|
|
|
|
nl_template_start = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after each ',' in a template parameter list.
|
|
|
|
nl_template_args = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline before '>' of a template parameter list.
|
|
|
|
nl_template_end = false # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to put each Objective-C message parameter on a separate line.
|
|
|
|
# See nl_oc_msg_leave_one_liner.
|
|
|
|
nl_oc_msg_args = false # true/false
|
|
|
|
|
|
|
|
# Add or remove newline between function signature and '{'.
|
|
|
|
nl_fdef_brace = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between function signature and '{',
|
|
|
|
# if signature ends with ')'. Overrides nl_fdef_brace.
|
|
|
|
nl_fdef_brace_cond = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between C++11 lambda signature and '{'.
|
|
|
|
nl_cpp_ldef_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline between 'return' and the return expression.
|
|
|
|
nl_return_expr = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline after semicolons, except in 'for' statements.
|
|
|
|
nl_after_semicolon = true # true/false
|
|
|
|
|
|
|
|
# (Java) Add or remove newline between the ')' and '{{' of the double brace
|
|
|
|
# initializer.
|
|
|
|
nl_paren_dbrace_open = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline after the type in an unnamed temporary
|
|
|
|
# direct-list-initialization.
|
|
|
|
nl_type_brace_init_lst = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline after the open brace in an unnamed temporary
|
|
|
|
# direct-list-initialization.
|
|
|
|
nl_type_brace_init_lst_open = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline before the close brace in an unnamed temporary
|
|
|
|
# direct-list-initialization.
|
|
|
|
nl_type_brace_init_lst_close = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to add a newline after '{'. This also adds a newline before the
|
|
|
|
# matching '}'.
|
|
|
|
nl_after_brace_open = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline between the open brace and a trailing single-line
|
|
|
|
# comment. Requires nl_after_brace_open=true.
|
|
|
|
nl_after_brace_open_cmt = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after a virtual brace open with a non-empty body.
|
|
|
|
# These occur in un-braced if/while/do/for statement bodies.
|
|
|
|
nl_after_vbrace_open = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after a virtual brace open with an empty body.
|
|
|
|
# These occur in un-braced if/while/do/for statement bodies.
|
|
|
|
nl_after_vbrace_open_empty = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after '}'. Does not apply if followed by a
|
|
|
|
# necessary ';'.
|
|
|
|
nl_after_brace_close = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline after a virtual brace close,
|
|
|
|
# as in 'if (foo) a++; <here> return;'.
|
|
|
|
nl_after_vbrace_close = false # true/false
|
|
|
|
|
|
|
|
# Add or remove newline between the close brace and identifier,
|
|
|
|
# as in 'struct { int a; } <here> b;'. Affects enumerations, unions and
|
|
|
|
# structures. If set to ignore, uses nl_after_brace_close.
|
|
|
|
nl_brace_struct_var = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to alter newlines in '#define' macros.
|
|
|
|
nl_define_macro = false # true/false
|
|
|
|
|
|
|
|
# Whether to alter newlines between consecutive parenthesis closes. The number
|
|
|
|
# of closing parentheses in a line will depend on respective open parenthesis
|
|
|
|
# lines.
|
|
|
|
nl_squeeze_paren_close = false # true/false
|
|
|
|
|
|
|
|
# Whether to remove blanks after '#ifxx' and '#elxx', or before '#elxx' and
|
|
|
|
# '#endif'. Does not affect top-level #ifdefs.
|
|
|
|
nl_squeeze_ifdef = false # true/false
|
|
|
|
|
|
|
|
# Makes the nl_squeeze_ifdef option affect the top-level #ifdefs as well.
|
|
|
|
nl_squeeze_ifdef_top_level = false # true/false
|
|
|
|
|
|
|
|
# Add or remove blank line before 'if'.
|
|
|
|
nl_before_if = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line after 'if' statement. Add/Force work only if the
|
|
|
|
# next token is not a closing brace.
|
|
|
|
nl_after_if = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line before 'for'.
|
|
|
|
nl_before_for = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line after 'for' statement.
|
|
|
|
nl_after_for = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line before 'while'.
|
|
|
|
nl_before_while = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line after 'while' statement.
|
|
|
|
nl_after_while = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line before 'switch'.
|
|
|
|
nl_before_switch = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line after 'switch' statement.
|
|
|
|
nl_after_switch = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line before 'synchronized'.
|
|
|
|
nl_before_synchronized = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line after 'synchronized' statement.
|
|
|
|
nl_after_synchronized = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line before 'do'.
|
|
|
|
nl_before_do = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove blank line after 'do/while' statement.
|
|
|
|
nl_after_do = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to put a blank line before 'return' statements, unless after an open
|
|
|
|
# brace.
|
|
|
|
nl_before_return = false # true/false
|
|
|
|
|
|
|
|
# Whether to put a blank line after 'return' statements, unless followed by a
|
|
|
|
# close brace.
|
|
|
|
nl_after_return = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Whether to put a blank line before a member '.' or '->' operators.
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
nl_before_member = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (Java) Whether to put a blank line after a member '.' or '->' operators.
|
|
|
|
nl_after_member = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to double-space commented-entries in 'struct'/'union'/'enum'.
|
|
|
|
nl_ds_struct_enum_cmt = false # true/false
|
|
|
|
|
|
|
|
# Whether to force a newline before '}' of a 'struct'/'union'/'enum'.
|
|
|
|
# (Lower priority than eat_blanks_before_close_brace.)
|
|
|
|
nl_ds_struct_enum_close_brace = false # true/false
|
|
|
|
|
|
|
|
# Add or remove newline before or after (depending on pos_class_colon) a class
|
|
|
|
# colon, as in 'class Foo <here> : <or here> public Bar'.
|
|
|
|
nl_class_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove newline around a class constructor colon. The exact position
|
|
|
|
# depends on nl_constr_init_args, pos_constr_colon and pos_constr_comma.
|
|
|
|
nl_constr_colon = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to collapse a two-line namespace, like 'namespace foo\n{ decl; }'
|
|
|
|
# into a single line. If true, prevents other brace newline rules from turning
|
|
|
|
# such code into four lines.
|
|
|
|
nl_namespace_two_to_one_liner = false # true/false
|
|
|
|
|
|
|
|
# Whether to remove a newline in simple unbraced if statements, turning them
|
|
|
|
# into one-liners, as in 'if(b)\n i++;' => 'if(b) i++;'.
|
|
|
|
nl_create_if_one_liner = false # true/false
|
|
|
|
|
|
|
|
# Whether to remove a newline in simple unbraced for statements, turning them
|
|
|
|
# into one-liners, as in 'for (...)\n stmt;' => 'for (...) stmt;'.
|
|
|
|
nl_create_for_one_liner = false # true/false
|
|
|
|
|
|
|
|
# Whether to remove a newline in simple unbraced while statements, turning
|
|
|
|
# them into one-liners, as in 'while (expr)\n stmt;' => 'while (expr) stmt;'.
|
|
|
|
nl_create_while_one_liner = false # true/false
|
|
|
|
|
|
|
|
# Whether to collapse a function definition whose body (not counting braces)
|
|
|
|
# is only one line so that the entire definition (prototype, braces, body) is
|
|
|
|
# a single line.
|
|
|
|
nl_create_func_def_one_liner = false # true/false
|
|
|
|
|
|
|
|
# Whether to collapse a function definition whose body (not counting braces)
|
|
|
|
# is only one line so that the entire definition (prototype, braces, body) is
|
|
|
|
# a single line.
|
|
|
|
nl_create_list_one_liner = false # true/false
|
|
|
|
|
|
|
|
# Whether to split one-line simple unbraced if statements into two lines by
|
|
|
|
# adding a newline, as in 'if(b) <here> i++;'.
|
|
|
|
nl_split_if_one_liner = true # true/false
|
|
|
|
|
|
|
|
# Whether to split one-line simple unbraced for statements into two lines by
|
|
|
|
# adding a newline, as in 'for (...) <here> stmt;'.
|
|
|
|
nl_split_for_one_liner = true # true/false
|
|
|
|
|
|
|
|
# Whether to split one-line simple unbraced while statements into two lines by
|
|
|
|
# adding a newline, as in 'while (expr) <here> stmt;'.
|
|
|
|
nl_split_while_one_liner = true # true/false
|
|
|
|
|
|
|
|
#
|
|
|
|
# Blank line options
|
|
|
|
#
|
|
|
|
|
|
|
|
# The maximum number of consecutive newlines (3 = 2 blank lines).
|
|
|
|
nl_max = 0 # unsigned number
|
|
|
|
|
|
|
|
# The maximum number of consecutive newlines in a function.
|
|
|
|
nl_max_blank_in_func = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a function prototype.
|
|
|
|
nl_before_func_body_proto = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a multi-line function definition.
|
|
|
|
nl_before_func_body_def = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a class constructor/destructor prototype.
|
|
|
|
nl_before_func_class_proto = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a class constructor/destructor definition.
|
|
|
|
nl_before_func_class_def = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a function prototype.
|
|
|
|
nl_after_func_proto = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a function prototype, if not followed by
|
|
|
|
# another function prototype.
|
|
|
|
nl_after_func_proto_group = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a class constructor/destructor prototype.
|
|
|
|
nl_after_func_class_proto = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a class constructor/destructor prototype,
|
|
|
|
# if not followed by another constructor/destructor prototype.
|
|
|
|
nl_after_func_class_proto_group = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether one-line method definitions inside a class body should be treated
|
|
|
|
# as if they were prototypes for the purposes of adding newlines.
|
|
|
|
#
|
|
|
|
# Requires nl_class_leave_one_liners=true. Overrides nl_before_func_body_def
|
|
|
|
# and nl_before_func_class_def for one-liners.
|
|
|
|
nl_class_leave_one_liner_groups = false # true/false
|
|
|
|
|
|
|
|
# The number of newlines after '}' of a multi-line function body.
|
|
|
|
nl_after_func_body = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after '}' of a multi-line function body in a class
|
|
|
|
# declaration. Also affects class constructors/destructors.
|
|
|
|
#
|
|
|
|
# Overrides nl_after_func_body.
|
|
|
|
nl_after_func_body_class = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after '}' of a single line function body. Also
|
|
|
|
# affects class constructors/destructors.
|
|
|
|
#
|
|
|
|
# Overrides nl_after_func_body and nl_after_func_body_class.
|
|
|
|
nl_after_func_body_one_liner = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of blank lines after a block of variable definitions at the top
|
|
|
|
# of a function body.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_func_var_def_blk = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a block of typedefs. If nl_after_access_spec
|
|
|
|
# is non-zero, that option takes precedence.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_typedef_blk_start = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a block of typedefs.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_typedef_blk_end = 0 # unsigned number
|
|
|
|
|
|
|
|
# The maximum number of consecutive newlines within a block of typedefs.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_typedef_blk_in = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a block of variable definitions not at the top
|
|
|
|
# of a function body. If nl_after_access_spec is non-zero, that option takes
|
|
|
|
# precedence.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_var_def_blk_start = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a block of variable definitions not at the top
|
|
|
|
# of a function body.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_var_def_blk_end = 0 # unsigned number
|
|
|
|
|
|
|
|
# The maximum number of consecutive newlines within a block of variable
|
|
|
|
# definitions.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_var_def_blk_in = 0 # unsigned number
|
|
|
|
|
|
|
|
# The minimum number of newlines before a multi-line comment.
|
|
|
|
# Doesn't apply if after a brace open or another multi-line comment.
|
|
|
|
nl_before_block_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# The minimum number of newlines before a single-line C comment.
|
|
|
|
# Doesn't apply if after a brace open or other single-line C comments.
|
|
|
|
nl_before_c_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# The minimum number of newlines before a CPP comment.
|
|
|
|
# Doesn't apply if after a brace open or other CPP comments.
|
|
|
|
nl_before_cpp_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to force a newline after a multi-line comment.
|
|
|
|
nl_after_multiline_comment = false # true/false
|
|
|
|
|
|
|
|
# Whether to force a newline after a label's colon.
|
|
|
|
nl_after_label_colon = false # true/false
|
|
|
|
|
|
|
|
# The number of newlines after '}' or ';' of a struct/enum/union definition.
|
|
|
|
nl_after_struct = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a class definition.
|
|
|
|
nl_before_class = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after '}' or ';' of a class definition.
|
|
|
|
nl_after_class = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a namespace.
|
|
|
|
nl_before_namespace = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after '{' of a namespace. This also adds newlines
|
|
|
|
# before the matching '}'.
|
|
|
|
#
|
|
|
|
# 0: Apply eat_blanks_after_open_brace or eat_blanks_before_close_brace if
|
|
|
|
# applicable, otherwise no change.
|
|
|
|
#
|
|
|
|
# Overrides eat_blanks_after_open_brace and eat_blanks_before_close_brace.
|
|
|
|
nl_inside_namespace = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after '}' of a namespace.
|
|
|
|
nl_after_namespace = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before an access specifier label. This also includes
|
|
|
|
# the Qt-specific 'signals:' and 'slots:'. Will not change the newline count
|
|
|
|
# if after a brace open.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_before_access_spec = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after an access specifier label. This also includes
|
|
|
|
# the Qt-specific 'signals:' and 'slots:'. Will not change the newline count
|
|
|
|
# if after a brace open.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
#
|
|
|
|
# Overrides nl_typedef_blk_start and nl_var_def_blk_start.
|
|
|
|
nl_after_access_spec = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines between a function definition and the function
|
|
|
|
# comment, as in '// comment\n <here> void foo() {...}'.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_comment_func_def = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a try-catch-finally block that isn't followed
|
|
|
|
# by a brace close.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_after_try_catch_finally = 0 # unsigned number
|
|
|
|
|
|
|
|
# (C#) The number of newlines before and after a property, indexer or event
|
|
|
|
# declaration.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_around_cs_property = 0 # unsigned number
|
|
|
|
|
|
|
|
# (C#) The number of newlines between the get/set/add/remove handlers.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_between_get_set = 0 # unsigned number
|
|
|
|
|
|
|
|
# (C#) Add or remove newline between property and the '{'.
|
|
|
|
nl_property_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to remove blank lines after '{'.
|
|
|
|
eat_blanks_after_open_brace = false # true/false
|
|
|
|
|
|
|
|
# Whether to remove blank lines before '}'.
|
|
|
|
eat_blanks_before_close_brace = false # true/false
|
|
|
|
|
|
|
|
# How aggressively to remove extra newlines not in preprocessor.
|
|
|
|
#
|
|
|
|
# 0: No change (default)
|
|
|
|
# 1: Remove most newlines not handled by other config
|
|
|
|
# 2: Remove all newlines and reformat completely by config
|
|
|
|
nl_remove_extra_newlines = 0 # unsigned number
|
|
|
|
|
|
|
|
# (Java) Add or remove newline after an annotation statement. Only affects
|
|
|
|
# annotations that are after a newline.
|
|
|
|
nl_after_annotation = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (Java) Add or remove newline between two annotations.
|
|
|
|
nl_between_annotation = ignore # ignore/add/remove/force
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# The number of newlines before a whole-file #ifdef.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_before_whole_file_ifdef = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a whole-file #ifdef.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_after_whole_file_ifdef = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines before a whole-file #endif.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_before_whole_file_endif = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of newlines after a whole-file #endif.
|
|
|
|
#
|
|
|
|
# 0: No change (default).
|
|
|
|
nl_after_whole_file_endif = 0 # unsigned number
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
# Positioning options
|
|
|
|
#
|
|
|
|
|
|
|
|
# The position of arithmetic operators in wrapped expressions.
|
|
|
|
pos_arith = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of assignment in wrapped expressions. Do not affect '='
|
|
|
|
# followed by '{'.
|
|
|
|
pos_assign = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of Boolean operators in wrapped expressions.
|
|
|
|
pos_bool = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of comparison operators in wrapped expressions.
|
|
|
|
pos_compare = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of conditional operators, as in the '?' and ':' of
|
|
|
|
# 'expr ? stmt : stmt', in wrapped expressions.
|
|
|
|
pos_conditional = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of the comma in wrapped expressions.
|
|
|
|
pos_comma = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of the comma in enum entries.
|
|
|
|
pos_enum_comma = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of the comma in the base class list if there is more than one
|
|
|
|
# line. Affects nl_class_init_args.
|
|
|
|
pos_class_comma = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of the comma in the constructor initialization list.
|
|
|
|
# Related to nl_constr_colon, nl_constr_init_args and pos_constr_colon.
|
|
|
|
pos_constr_comma = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of trailing/leading class colon, between class and base class
|
|
|
|
# list. Affects nl_class_colon.
|
|
|
|
pos_class_colon = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
# The position of colons between constructor and member initialization.
|
|
|
|
# Related to nl_constr_colon, nl_constr_init_args and pos_constr_comma.
|
|
|
|
pos_constr_colon = ignore # ignore/break/force/lead/trail/join/lead_break/lead_force/trail_break/trail_force
|
|
|
|
|
|
|
|
#
|
|
|
|
# Line splitting options
|
|
|
|
#
|
|
|
|
|
|
|
|
# Try to limit code width to N columns.
|
|
|
|
code_width = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to fully split long 'for' statements at semi-colons.
|
|
|
|
ls_for_split_full = false # true/false
|
|
|
|
|
|
|
|
# Whether to fully split long function prototypes/calls at commas.
|
|
|
|
# The option ls_code_width has priority over the option ls_func_split_full.
|
|
|
|
ls_func_split_full = false # true/false
|
|
|
|
|
|
|
|
# Whether to split lines as close to code_width as possible and ignore some
|
|
|
|
# groupings.
|
|
|
|
# The option ls_code_width has priority over the option ls_func_split_full.
|
|
|
|
ls_code_width = false # true/false
|
|
|
|
|
|
|
|
#
|
|
|
|
# Code alignment options (not left column spaces/tabs)
|
|
|
|
#
|
|
|
|
|
|
|
|
# Whether to keep non-indenting tabs.
|
|
|
|
align_keep_tabs = false # true/false
|
|
|
|
|
|
|
|
# Whether to use tabs for aligning.
|
|
|
|
align_with_tabs = false # true/false
|
|
|
|
|
|
|
|
# Whether to bump out to the next tab when aligning.
|
|
|
|
align_on_tabstop = false # true/false
|
|
|
|
|
|
|
|
# Whether to right-align numbers.
|
|
|
|
align_number_right = false # true/false
|
|
|
|
|
|
|
|
# Whether to keep whitespace not required for alignment.
|
|
|
|
align_keep_extra_space = false # true/false
|
|
|
|
|
|
|
|
# Whether to align variable definitions in prototypes and functions.
|
|
|
|
align_func_params = false # true/false
|
|
|
|
|
|
|
|
# The span for aligning parameter definitions in function on parameter name.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_func_params_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning function parameter definitions.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_func_params_thresh = 0 # number
|
|
|
|
|
|
|
|
# The gap for aligning function parameter definitions.
|
|
|
|
align_func_params_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning constructor value.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_constr_value_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning constructor value.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_constr_value_thresh = 0 # number
|
|
|
|
|
|
|
|
# The gap for aligning constructor value.
|
|
|
|
align_constr_value_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to align parameters in single-line functions that have the same
|
|
|
|
# name. The function names must already be aligned with each other.
|
|
|
|
align_same_func_call_params = false # true/false
|
|
|
|
|
|
|
|
# The span for aligning function-call parameters for single line functions.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_same_func_call_params_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning function-call parameters for single line
|
|
|
|
# functions.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_same_func_call_params_thresh = 0 # number
|
|
|
|
|
|
|
|
# The span for aligning variable definitions.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_var_def_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to consider (or treat) the '*' in the alignment of variable definitions.
|
|
|
|
#
|
|
|
|
# 0: Part of the type 'void * foo;' (default)
|
|
|
|
# 1: Part of the variable 'void *foo;'
|
|
|
|
# 2: Dangling 'void *foo;'
|
|
|
|
# Dangling: the '*' will not be taken into account when aligning.
|
|
|
|
align_var_def_star_style = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to consider (or treat) the '&' in the alignment of variable definitions.
|
|
|
|
#
|
|
|
|
# 0: Part of the type 'long & foo;' (default)
|
|
|
|
# 1: Part of the variable 'long &foo;'
|
|
|
|
# 2: Dangling 'long &foo;'
|
|
|
|
# Dangling: the '&' will not be taken into account when aligning.
|
|
|
|
align_var_def_amp_style = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning variable definitions.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_var_def_thresh = 0 # number
|
|
|
|
|
|
|
|
# The gap for aligning variable definitions.
|
|
|
|
align_var_def_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to align the colon in struct bit fields.
|
|
|
|
align_var_def_colon = false # true/false
|
|
|
|
|
|
|
|
# The gap for aligning the colon in struct bit fields.
|
|
|
|
align_var_def_colon_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to align any attribute after the variable name.
|
|
|
|
align_var_def_attribute = false # true/false
|
|
|
|
|
|
|
|
# Whether to align inline struct/enum/union variable definitions.
|
|
|
|
align_var_def_inline = false # true/false
|
|
|
|
|
|
|
|
# The span for aligning on '=' in assignments.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_assign_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning on '=' in function prototype modifier.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_assign_func_proto_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning on '=' in assignments.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_assign_thresh = 0 # number
|
|
|
|
|
|
|
|
# How to apply align_assign_span to function declaration "assignments", i.e.
|
|
|
|
# 'virtual void foo() = 0' or '~foo() = {default|delete}'.
|
|
|
|
#
|
|
|
|
# 0: Align with other assignments (default)
|
|
|
|
# 1: Align with each other, ignoring regular assignments
|
|
|
|
# 2: Don't align
|
|
|
|
align_assign_decl_func = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning on '=' in enums.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_enum_equ_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning on '=' in enums.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: no limit (default).
|
|
|
|
align_enum_equ_thresh = 0 # number
|
|
|
|
|
|
|
|
# The span for aligning class member definitions.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_var_class_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning class member definitions.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_var_class_thresh = 0 # number
|
|
|
|
|
|
|
|
# The gap for aligning class member definitions.
|
|
|
|
align_var_class_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning struct/union member definitions.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_var_struct_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning struct/union member definitions.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_var_struct_thresh = 0 # number
|
|
|
|
|
|
|
|
# The gap for aligning struct/union member definitions.
|
|
|
|
align_var_struct_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning struct initializer values.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_struct_init_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning single-line typedefs.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_typedef_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The minimum space between the type and the synonym of a typedef.
|
|
|
|
align_typedef_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to align typedef'd functions with other typedefs.
|
|
|
|
#
|
|
|
|
# 0: Don't mix them at all (default)
|
|
|
|
# 1: Align the open parenthesis with the types
|
|
|
|
# 2: Align the function type name with the other type names
|
|
|
|
align_typedef_func = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to consider (or treat) the '*' in the alignment of typedefs.
|
|
|
|
#
|
|
|
|
# 0: Part of the typedef type, 'typedef int * pint;' (default)
|
|
|
|
# 1: Part of type name: 'typedef int *pint;'
|
|
|
|
# 2: Dangling: 'typedef int *pint;'
|
|
|
|
# Dangling: the '*' will not be taken into account when aligning.
|
|
|
|
align_typedef_star_style = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to consider (or treat) the '&' in the alignment of typedefs.
|
|
|
|
#
|
|
|
|
# 0: Part of the typedef type, 'typedef int & intref;' (default)
|
|
|
|
# 1: Part of type name: 'typedef int &intref;'
|
|
|
|
# 2: Dangling: 'typedef int &intref;'
|
|
|
|
# Dangling: the '&' will not be taken into account when aligning.
|
|
|
|
align_typedef_amp_style = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning comments that end lines.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_right_cmt_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# Minimum number of columns between preceding text and a trailing comment in
|
|
|
|
# order for the comment to qualify for being aligned. Must be non-zero to have
|
|
|
|
# an effect.
|
|
|
|
align_right_cmt_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# If aligning comments, whether to mix with comments after '}' and #endif with
|
|
|
|
# less than three spaces before the comment.
|
|
|
|
align_right_cmt_mix = false # true/false
|
|
|
|
|
|
|
|
# Whether to only align trailing comments that are at the same brace level.
|
|
|
|
align_right_cmt_same_level = false # true/false
|
|
|
|
|
|
|
|
# Minimum column at which to align trailing comments. Comments which are
|
|
|
|
# aligned beyond this column, but which can be aligned in a lesser column,
|
|
|
|
# may be "pulled in".
|
|
|
|
#
|
|
|
|
# 0: Ignore (default).
|
|
|
|
align_right_cmt_at_col = 0 # unsigned number
|
|
|
|
|
|
|
|
# The span for aligning function prototypes.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_func_proto_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The threshold for aligning function prototypes.
|
|
|
|
# Use a negative number for absolute thresholds.
|
|
|
|
#
|
|
|
|
# 0: No limit (default).
|
|
|
|
align_func_proto_thresh = 0 # number
|
|
|
|
|
|
|
|
# Minimum gap between the return type and the function name.
|
|
|
|
align_func_proto_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to align function prototypes on the 'operator' keyword instead of
|
|
|
|
# what follows.
|
|
|
|
align_on_operator = false # true/false
|
|
|
|
|
|
|
|
# Whether to mix aligning prototype and variable declarations. If true,
|
|
|
|
# align_var_def_XXX options are used instead of align_func_proto_XXX options.
|
|
|
|
align_mix_var_proto = false # true/false
|
|
|
|
|
|
|
|
# Whether to align single-line functions with function prototypes.
|
|
|
|
# Uses align_func_proto_span.
|
|
|
|
align_single_line_func = false # true/false
|
|
|
|
|
|
|
|
# Whether to align the open brace of single-line functions.
|
|
|
|
# Requires align_single_line_func=true. Uses align_func_proto_span.
|
|
|
|
align_single_line_brace = false # true/false
|
|
|
|
|
|
|
|
# Gap for align_single_line_brace.
|
|
|
|
align_single_line_brace_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# (OC) The span for aligning Objective-C message specifications.
|
|
|
|
#
|
|
|
|
# 0: Don't align (default).
|
|
|
|
align_oc_msg_spec_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to align macros wrapped with a backslash and a newline. This will
|
|
|
|
# not work right if the macro contains a multi-line comment.
|
|
|
|
align_nl_cont = false # true/false
|
|
|
|
|
|
|
|
# Whether to align macro functions and variables together.
|
|
|
|
align_pp_define_together = false # true/false
|
|
|
|
|
|
|
|
# The span for aligning on '#define' bodies.
|
|
|
|
#
|
|
|
|
# =0: Don't align (default)
|
|
|
|
# >0: Number of lines (including comments) between blocks
|
|
|
|
align_pp_define_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# The minimum space between label and value of a preprocessor define.
|
|
|
|
align_pp_define_gap = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to align lines that start with '<<' with previous '<<'.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
align_left_shift = true # true/false
|
|
|
|
|
|
|
|
# Whether to align text after 'asm volatile ()' colons.
|
|
|
|
align_asm_colon = false # true/false
|
|
|
|
|
|
|
|
# (OC) Span for aligning parameters in an Objective-C message call
|
|
|
|
# on the ':'.
|
|
|
|
#
|
|
|
|
# 0: Don't align.
|
|
|
|
align_oc_msg_colon_span = 0 # unsigned number
|
|
|
|
|
|
|
|
# (OC) Whether to always align with the first parameter, even if it is too
|
|
|
|
# short.
|
|
|
|
align_oc_msg_colon_first = false # true/false
|
|
|
|
|
|
|
|
# (OC) Whether to align parameters in an Objective-C '+' or '-' declaration
|
|
|
|
# on the ':'.
|
|
|
|
align_oc_decl_colon = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# (OC) Whether to not align parameters in an Objectve-C message call if first
|
|
|
|
# colon is not on next line of the message call (the same way Xcode does
|
2023-03-18 11:17:02 -04:00
|
|
|
# alignment)
|
2020-06-14 12:02:19 -04:00
|
|
|
align_oc_msg_colon_xcode_like = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
# Comment modification options
|
|
|
|
#
|
|
|
|
|
|
|
|
# Try to wrap comments at N columns.
|
|
|
|
cmt_width = 0 # unsigned number
|
|
|
|
|
|
|
|
# How to reflow comments.
|
|
|
|
#
|
|
|
|
# 0: No reflowing (apart from the line wrapping due to cmt_width) (default)
|
|
|
|
# 1: No touching at all
|
|
|
|
# 2: Full reflow
|
|
|
|
cmt_reflow_mode = 1 # unsigned number
|
|
|
|
|
|
|
|
# Whether to convert all tabs to spaces in comments. If false, tabs in
|
|
|
|
# comments are left alone, unless used for indenting.
|
|
|
|
cmt_convert_tab_to_spaces = false # true/false
|
|
|
|
|
|
|
|
# Whether to apply changes to multi-line comments, including cmt_width,
|
|
|
|
# keyword substitution and leading chars.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
cmt_indent_multi = false # true/false
|
|
|
|
|
|
|
|
# Whether to group c-comments that look like they are in a block.
|
|
|
|
cmt_c_group = false # true/false
|
|
|
|
|
|
|
|
# Whether to put an empty '/*' on the first line of the combined c-comment.
|
|
|
|
cmt_c_nl_start = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline before the closing '*/' of the combined c-comment.
|
|
|
|
cmt_c_nl_end = false # true/false
|
|
|
|
|
|
|
|
# Whether to change cpp-comments into c-comments.
|
|
|
|
cmt_cpp_to_c = false # true/false
|
|
|
|
|
|
|
|
# Whether to group cpp-comments that look like they are in a block. Only
|
|
|
|
# meaningful if cmt_cpp_to_c=true.
|
|
|
|
cmt_cpp_group = false # true/false
|
|
|
|
|
|
|
|
# Whether to put an empty '/*' on the first line of the combined cpp-comment
|
|
|
|
# when converting to a c-comment.
|
|
|
|
#
|
|
|
|
# Requires cmt_cpp_to_c=true and cmt_cpp_group=true.
|
|
|
|
cmt_cpp_nl_start = false # true/false
|
|
|
|
|
|
|
|
# Whether to add a newline before the closing '*/' of the combined cpp-comment
|
|
|
|
# when converting to a c-comment.
|
|
|
|
#
|
|
|
|
# Requires cmt_cpp_to_c=true and cmt_cpp_group=true.
|
|
|
|
cmt_cpp_nl_end = false # true/false
|
|
|
|
|
|
|
|
# Whether to put a star on subsequent comment lines.
|
|
|
|
cmt_star_cont = false # true/false
|
|
|
|
|
|
|
|
# The number of spaces to insert at the start of subsequent comment lines.
|
|
|
|
cmt_sp_before_star_cont = 0 # unsigned number
|
|
|
|
|
|
|
|
# The number of spaces to insert after the star on subsequent comment lines.
|
|
|
|
cmt_sp_after_star_cont = 0 # unsigned number
|
|
|
|
|
|
|
|
# For multi-line comments with a '*' lead, remove leading spaces if the first
|
|
|
|
# and last lines of the comment are the same length.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
cmt_multi_check_last = true # true/false
|
|
|
|
|
|
|
|
# For multi-line comments with a '*' lead, remove leading spaces if the first
|
|
|
|
# and last lines of the comment are the same length AND if the length is
|
|
|
|
# bigger as the first_len minimum.
|
|
|
|
#
|
|
|
|
# Default: 4
|
|
|
|
cmt_multi_first_len_minimum = 4 # unsigned number
|
|
|
|
|
|
|
|
# Path to a file that contains text to insert at the beginning of a file if
|
|
|
|
# the file doesn't start with a C/C++ comment. If the inserted text contains
|
|
|
|
# '$(filename)', that will be replaced with the current file's name.
|
|
|
|
cmt_insert_file_header = "" # string
|
|
|
|
|
|
|
|
# Path to a file that contains text to insert at the end of a file if the
|
|
|
|
# file doesn't end with a C/C++ comment. If the inserted text contains
|
|
|
|
# '$(filename)', that will be replaced with the current file's name.
|
|
|
|
cmt_insert_file_footer = "" # string
|
|
|
|
|
|
|
|
# Path to a file that contains text to insert before a function definition if
|
|
|
|
# the function isn't preceded by a C/C++ comment. If the inserted text
|
|
|
|
# contains '$(function)', '$(javaparam)' or '$(fclass)', these will be
|
|
|
|
# replaced with, respectively, the name of the function, the javadoc '@param'
|
|
|
|
# and '@return' stuff, or the name of the class to which the member function
|
|
|
|
# belongs.
|
|
|
|
cmt_insert_func_header = "" # string
|
|
|
|
|
|
|
|
# Path to a file that contains text to insert before a class if the class
|
|
|
|
# isn't preceded by a C/C++ comment. If the inserted text contains '$(class)',
|
|
|
|
# that will be replaced with the class name.
|
|
|
|
cmt_insert_class_header = "" # string
|
|
|
|
|
|
|
|
# Path to a file that contains text to insert before an Objective-C message
|
|
|
|
# specification, if the method isn't preceded by a C/C++ comment. If the
|
|
|
|
# inserted text contains '$(message)' or '$(javaparam)', these will be
|
|
|
|
# replaced with, respectively, the name of the function, or the javadoc
|
|
|
|
# '@param' and '@return' stuff.
|
|
|
|
cmt_insert_oc_msg_header = "" # string
|
|
|
|
|
|
|
|
# Whether a comment should be inserted if a preprocessor is encountered when
|
|
|
|
# stepping backwards from a function name.
|
|
|
|
#
|
|
|
|
# Applies to cmt_insert_oc_msg_header, cmt_insert_func_header and
|
|
|
|
# cmt_insert_class_header.
|
|
|
|
cmt_insert_before_preproc = false # true/false
|
|
|
|
|
|
|
|
# Whether a comment should be inserted if a function is declared inline to a
|
|
|
|
# class definition.
|
|
|
|
#
|
|
|
|
# Applies to cmt_insert_func_header.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
cmt_insert_before_inlines = true # true/false
|
|
|
|
|
|
|
|
# Whether a comment should be inserted if the function is a class constructor
|
|
|
|
# or destructor.
|
|
|
|
#
|
|
|
|
# Applies to cmt_insert_func_header.
|
|
|
|
cmt_insert_before_ctor_dtor = false # true/false
|
|
|
|
|
|
|
|
#
|
|
|
|
# Code modifying options (non-whitespace)
|
|
|
|
#
|
|
|
|
|
|
|
|
# Add or remove braces on a single-line 'do' statement.
|
|
|
|
mod_full_brace_do = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove braces on a single-line 'for' statement.
|
|
|
|
mod_full_brace_for = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (Pawn) Add or remove braces on a single-line function definition.
|
|
|
|
mod_full_brace_function = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove braces on a single-line 'if' statement. Braces will not be
|
|
|
|
# removed if the braced statement contains an 'else'.
|
|
|
|
mod_full_brace_if = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to enforce that all blocks of an 'if'/'else if'/'else' chain either
|
|
|
|
# have, or do not have, braces. If true, braces will be added if any block
|
|
|
|
# needs braces, and will only be removed if they can be removed from all
|
|
|
|
# blocks.
|
|
|
|
#
|
|
|
|
# Overrides mod_full_brace_if.
|
|
|
|
mod_full_brace_if_chain = false # true/false
|
|
|
|
|
|
|
|
# Whether to add braces to all blocks of an 'if'/'else if'/'else' chain.
|
|
|
|
# If true, mod_full_brace_if_chain will only remove braces from an 'if' that
|
|
|
|
# does not have an 'else if' or 'else'.
|
|
|
|
mod_full_brace_if_chain_only = false # true/false
|
|
|
|
|
|
|
|
# Add or remove braces on single-line 'while' statement.
|
|
|
|
mod_full_brace_while = force # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Add or remove braces on single-line 'using ()' statement.
|
|
|
|
mod_full_brace_using = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Don't remove braces around statements that span N newlines
|
|
|
|
mod_full_brace_nl = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to prevent removal of braces from 'if'/'for'/'while'/etc. blocks
|
|
|
|
# which span multiple lines.
|
|
|
|
#
|
|
|
|
# Affects:
|
|
|
|
# mod_full_brace_for
|
|
|
|
# mod_full_brace_if
|
|
|
|
# mod_full_brace_if_chain
|
|
|
|
# mod_full_brace_if_chain_only
|
|
|
|
# mod_full_brace_while
|
|
|
|
# mod_full_brace_using
|
|
|
|
#
|
|
|
|
# Does not affect:
|
|
|
|
# mod_full_brace_do
|
|
|
|
# mod_full_brace_function
|
|
|
|
mod_full_brace_nl_block_rem_mlcond = false # true/false
|
|
|
|
|
|
|
|
# Add or remove unnecessary parenthesis on 'return' statement.
|
|
|
|
mod_paren_on_return = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (Pawn) Whether to change optional semicolons to real semicolons.
|
|
|
|
mod_pawn_semicolon = false # true/false
|
|
|
|
|
|
|
|
# Whether to fully parenthesize Boolean expressions in 'while' and 'if'
|
|
|
|
# statement, as in 'if (a && b > c)' => 'if (a && (b > c))'.
|
|
|
|
mod_full_paren_if_bool = false # true/false
|
|
|
|
|
|
|
|
# Whether to remove superfluous semicolons.
|
|
|
|
mod_remove_extra_semicolon = false # true/false
|
|
|
|
|
|
|
|
# If a function body exceeds the specified number of newlines and doesn't have
|
|
|
|
# a comment after the close brace, a comment will be added.
|
|
|
|
mod_add_long_function_closebrace_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# If a namespace body exceeds the specified number of newlines and doesn't
|
|
|
|
# have a comment after the close brace, a comment will be added.
|
|
|
|
mod_add_long_namespace_closebrace_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# If a class body exceeds the specified number of newlines and doesn't have a
|
|
|
|
# comment after the close brace, a comment will be added.
|
|
|
|
mod_add_long_class_closebrace_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# If a switch body exceeds the specified number of newlines and doesn't have a
|
|
|
|
# comment after the close brace, a comment will be added.
|
|
|
|
mod_add_long_switch_closebrace_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# If an #ifdef body exceeds the specified number of newlines and doesn't have
|
|
|
|
# a comment after the #endif, a comment will be added.
|
|
|
|
mod_add_long_ifdef_endif_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# If an #ifdef or #else body exceeds the specified number of newlines and
|
|
|
|
# doesn't have a comment after the #else, a comment will be added.
|
|
|
|
mod_add_long_ifdef_else_comment = 0 # unsigned number
|
|
|
|
|
|
|
|
# Whether to take care of the case by the mod_sort_xx options.
|
|
|
|
mod_sort_case_sensitive = false # true/false
|
|
|
|
|
|
|
|
# Whether to sort consecutive single-line 'import' statements.
|
|
|
|
mod_sort_import = false # true/false
|
|
|
|
|
|
|
|
# (C#) Whether to sort consecutive single-line 'using' statements.
|
|
|
|
mod_sort_using = false # true/false
|
|
|
|
|
|
|
|
# Whether to sort consecutive single-line '#include' statements (C/C++) and
|
|
|
|
# '#import' statements (Objective-C). Be aware that this has the potential to
|
|
|
|
# break your code if your includes/imports have ordering dependencies.
|
|
|
|
mod_sort_include = false # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Whether to prioritize '#include' and '#import' statements that contain
|
|
|
|
# filename without extension when sorting is enabled.
|
|
|
|
mod_sort_incl_import_prioritize_filename = false # true/false
|
|
|
|
|
|
|
|
# Whether to prioritize '#include' and '#import' statements that does not
|
|
|
|
# contain extensions when sorting is enabled.
|
|
|
|
mod_sort_incl_import_prioritize_extensionless = false # true/false
|
|
|
|
|
|
|
|
# Whether to prioritize '#include' and '#import' statements that contain
|
|
|
|
# angle over quotes when sorting is enabled.
|
|
|
|
mod_sort_incl_import_prioritize_angle_over_quotes = false # true/false
|
|
|
|
|
|
|
|
# Whether to ignore file extension in '#include' and '#import' statements
|
|
|
|
# for sorting comparison.
|
|
|
|
mod_sort_incl_import_ignore_extension = false # true/false
|
|
|
|
|
|
|
|
# Whether to group '#include' and '#import' statements when sorting is enabled.
|
|
|
|
mod_sort_incl_import_grouping_enabled = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Whether to move a 'break' that appears after a fully braced 'case' before
|
|
|
|
# the close brace, as in 'case X: { ... } break;' => 'case X: { ... break; }'.
|
|
|
|
mod_move_case_break = false # true/false
|
|
|
|
|
|
|
|
# Add or remove braces around a fully braced case statement. Will only remove
|
|
|
|
# braces if there are no variable declarations in the block.
|
|
|
|
mod_case_brace = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to remove a void 'return;' that appears as the last statement in a
|
|
|
|
# function.
|
|
|
|
mod_remove_empty_return = false # true/false
|
|
|
|
|
|
|
|
# Add or remove the comma after the last value of an enumeration.
|
|
|
|
mod_enum_last_comma = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# (OC) Whether to organize the properties. If true, properties will be
|
|
|
|
# rearranged according to the mod_sort_oc_property_*_weight factors.
|
|
|
|
mod_sort_oc_properties = false # true/false
|
|
|
|
|
|
|
|
# (OC) Weight of a class property modifier.
|
|
|
|
mod_sort_oc_property_class_weight = 0 # number
|
|
|
|
|
|
|
|
# (OC) Weight of 'atomic' and 'nonatomic'.
|
|
|
|
mod_sort_oc_property_thread_safe_weight = 0 # number
|
|
|
|
|
|
|
|
# (OC) Weight of 'readwrite' when organizing properties.
|
|
|
|
mod_sort_oc_property_readwrite_weight = 0 # number
|
|
|
|
|
|
|
|
# (OC) Weight of a reference type specifier ('retain', 'copy', 'assign',
|
|
|
|
# 'weak', 'strong') when organizing properties.
|
|
|
|
mod_sort_oc_property_reference_weight = 0 # number
|
|
|
|
|
|
|
|
# (OC) Weight of getter type ('getter=') when organizing properties.
|
|
|
|
mod_sort_oc_property_getter_weight = 0 # number
|
|
|
|
|
|
|
|
# (OC) Weight of setter type ('setter=') when organizing properties.
|
|
|
|
mod_sort_oc_property_setter_weight = 0 # number
|
|
|
|
|
|
|
|
# (OC) Weight of nullability type ('nullable', 'nonnull', 'null_unspecified',
|
|
|
|
# 'null_resettable') when organizing properties.
|
|
|
|
mod_sort_oc_property_nullability_weight = 0 # number
|
|
|
|
|
|
|
|
#
|
|
|
|
# Preprocessor options
|
|
|
|
#
|
|
|
|
|
|
|
|
# Add or remove indentation of preprocessor directives inside #if blocks
|
|
|
|
# at brace level 0 (file-level).
|
|
|
|
pp_indent = ignore # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Whether to indent #if/#else/#endif at the brace level. If false, these are
|
|
|
|
# indented from column 1.
|
|
|
|
pp_indent_at_level = true # true/false
|
|
|
|
|
|
|
|
# Specifies the number of columns to indent preprocessors per level
|
|
|
|
# at brace level 0 (file-level). If pp_indent_at_level=false, also specifies
|
|
|
|
# the number of columns to indent preprocessors per level
|
|
|
|
# at brace level > 0 (function-level).
|
|
|
|
#
|
|
|
|
# Default: 1
|
|
|
|
pp_indent_count = 1 # unsigned number
|
|
|
|
|
|
|
|
# Add or remove space after # based on pp_level of #if blocks.
|
|
|
|
pp_space = remove # ignore/add/remove/force
|
|
|
|
|
|
|
|
# Sets the number of spaces per level added with pp_space.
|
|
|
|
pp_space_count = 0 # unsigned number
|
|
|
|
|
|
|
|
# The indent for '#region' and '#endregion' in C# and '#pragma region' in
|
|
|
|
# C/C++. Negative values decrease indent down to the first column.
|
|
|
|
pp_indent_region = 0 # number
|
|
|
|
|
|
|
|
# Whether to indent the code between #region and #endregion.
|
|
|
|
pp_region_indent_code = false # true/false
|
|
|
|
|
|
|
|
# If pp_indent_at_level=true, sets the indent for #if, #else and #endif when
|
|
|
|
# not at file-level. Negative values decrease indent down to the first column.
|
|
|
|
#
|
|
|
|
# =0: Indent preprocessors using output_tab_size
|
|
|
|
# >0: Column at which all preprocessors will be indented
|
|
|
|
pp_indent_if = 0 # number
|
|
|
|
|
|
|
|
# Whether to indent the code between #if, #else and #endif.
|
|
|
|
pp_if_indent_code = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent '#define' at the brace level. If false, these are
|
|
|
|
# indented from column 1.
|
|
|
|
pp_define_at_level = false # true/false
|
|
|
|
|
|
|
|
# Whether to ignore the '#define' body while formatting.
|
|
|
|
pp_ignore_define_body = false # true/false
|
|
|
|
|
|
|
|
# Whether to indent case statements between #if, #else, and #endif.
|
2023-03-18 11:17:02 -04:00
|
|
|
# Only applies to the indent of the preprocessor that the case statements
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# directly inside of.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
pp_indent_case = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent whole function definitions between #if, #else, and #endif.
|
2023-03-18 11:17:02 -04:00
|
|
|
# Only applies to the indent of the preprocessor that the function definition
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# is directly inside of.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
pp_indent_func_def = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent extern C blocks between #if, #else, and #endif.
|
2023-03-18 11:17:02 -04:00
|
|
|
# Only applies to the indent of the preprocessor that the extern block is
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# directly inside of.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
pp_indent_extern = true # true/false
|
|
|
|
|
|
|
|
# Whether to indent braces directly inside #if, #else, and #endif.
|
2023-03-18 11:17:02 -04:00
|
|
|
# Only applies to the indent of the preprocessor that the braces are directly
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# inside of.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
pp_indent_brace = true # true/false
|
|
|
|
|
|
|
|
#
|
|
|
|
# Sort includes options
|
|
|
|
#
|
|
|
|
|
|
|
|
# The regex for include category with priority 0.
|
|
|
|
include_category_0 = "" # string
|
|
|
|
|
|
|
|
# The regex for include category with priority 1.
|
|
|
|
include_category_1 = "" # string
|
|
|
|
|
|
|
|
# The regex for include category with priority 2.
|
|
|
|
include_category_2 = "" # string
|
|
|
|
|
|
|
|
#
|
|
|
|
# Use or Do not Use options
|
|
|
|
#
|
|
|
|
|
|
|
|
# true: indent_func_call_param will be used (default)
|
|
|
|
# false: indent_func_call_param will NOT be used
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
use_indent_func_call_param = true # true/false
|
|
|
|
|
|
|
|
# The value of the indentation for a continuation line is calculated
|
|
|
|
# differently if the statement is:
|
|
|
|
# - a declaration: your case with QString fileName ...
|
|
|
|
# - an assignment: your case with pSettings = new QSettings( ...
|
|
|
|
#
|
|
|
|
# At the second case the indentation value might be used twice:
|
|
|
|
# - at the assignment
|
|
|
|
# - at the function call (if present)
|
|
|
|
#
|
|
|
|
# To prevent the double use of the indentation value, use this option with the
|
|
|
|
# value 'true'.
|
|
|
|
#
|
|
|
|
# true: indent_continue will be used only once
|
|
|
|
# false: indent_continue will be used every time (default)
|
|
|
|
use_indent_continue_only_once = false # true/false
|
|
|
|
|
|
|
|
# The value might be used twice:
|
|
|
|
# - at the assignment
|
|
|
|
# - at the opening brace
|
|
|
|
#
|
|
|
|
# To prevent the double use of the indentation value, use this option with the
|
|
|
|
# value 'true'.
|
|
|
|
#
|
|
|
|
# true: indentation will be used only once
|
|
|
|
# false: indentation will be used every time (default)
|
|
|
|
indent_cpp_lambda_only_once = false # true/false
|
|
|
|
|
|
|
|
# Whether sp_after_angle takes precedence over sp_inside_fparen. This was the
|
|
|
|
# historic behavior, but is probably not the desired behavior, so this is off
|
|
|
|
# by default.
|
|
|
|
use_sp_after_angle_always = false # true/false
|
|
|
|
|
|
|
|
# Whether to apply special formatting for Qt SIGNAL/SLOT macros. Essentially,
|
|
|
|
# this tries to format these so that they match Qt's normalized form (i.e. the
|
|
|
|
# result of QMetaObject::normalizedSignature), which can slightly improve the
|
|
|
|
# performance of the QObject::connect call, rather than how they would
|
|
|
|
# otherwise be formatted.
|
|
|
|
#
|
|
|
|
# See options_for_QT.cpp for details.
|
|
|
|
#
|
|
|
|
# Default: true
|
|
|
|
use_options_overriding_for_qt_macros = true # true/false
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# If true: the form feed character is removed from the list
|
|
|
|
# of whitespace characters.
|
|
|
|
# See https://en.cppreference.com/w/cpp/string/byte/isspace
|
|
|
|
use_form_feed_no_more_as_whitespace_character = false # true/false
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
# Warn levels - 1: error, 2: warning (default), 3: note
|
|
|
|
#
|
|
|
|
|
|
|
|
# (C#) Warning is given if doing tab-to-\t replacement and we have found one
|
|
|
|
# in a C# verbatim string literal.
|
|
|
|
#
|
|
|
|
# Default: 2
|
|
|
|
warn_level_tabs_found_in_verbatim_string_literals = 2 # unsigned number
|
|
|
|
|
2020-06-14 12:02:19 -04:00
|
|
|
# Limit the number of loops.
|
|
|
|
# Used by uncrustify.cpp to exit from infinite loop.
|
|
|
|
# 0: no limit.
|
|
|
|
debug_max_number_of_loops = 0 # number
|
|
|
|
|
|
|
|
# Set the number of the line to protocol;
|
|
|
|
# Used in the function prot_the_line if the 2. parameter is zero.
|
|
|
|
# 0: nothing protocol.
|
|
|
|
debug_line_number_to_protocol = 0 # number
|
|
|
|
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
# Meaning of the settings:
|
|
|
|
# Ignore - do not do any changes
|
|
|
|
# Add - makes sure there is 1 or more space/brace/newline/etc
|
|
|
|
# Force - makes sure there is exactly 1 space/brace/newline/etc,
|
|
|
|
# behaves like Add in some contexts
|
|
|
|
# Remove - removes space/brace/newline/etc
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# - Token(s) can be treated as specific type(s) with the 'set' option:
|
|
|
|
# `set tokenType tokenString [tokenString...]`
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
# `set BOOL __AND__ __OR__`
|
|
|
|
#
|
|
|
|
# tokenTypes are defined in src/token_enum.h, use them without the
|
|
|
|
# 'CT_' prefix: 'CT_BOOL' => 'BOOL'
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# - Token(s) can be treated as type(s) with the 'type' option.
|
|
|
|
# `type tokenString [tokenString...]`
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
# `type int c_uint_8 Rectangle`
|
|
|
|
#
|
|
|
|
# This can also be achieved with `set TYPE int c_uint_8 Rectangle`
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# To embed whitespace in tokenStrings use the '\' escape character, or quote
|
|
|
|
# the tokenStrings. These quotes are supported: "'`
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# - Support for the auto detection of languages through the file ending can be
|
|
|
|
# added using the 'file_ext' command.
|
|
|
|
# `file_ext langType langString [langString..]`
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
# `file_ext CPP .ch .cxx .cpp.in`
|
|
|
|
#
|
|
|
|
# langTypes are defined in uncrusify_types.h in the lang_flag_e enum, use
|
|
|
|
# them without the 'LANG_' prefix: 'LANG_CPP' => 'CPP'
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# - Custom macro-based indentation can be set up using 'macro-open',
|
|
|
|
# 'macro-else' and 'macro-close'.
|
|
|
|
# `(macro-open | macro-else | macro-close) tokenString`
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
# `macro-open BEGIN_TEMPLATE_MESSAGE_MAP`
|
|
|
|
# `macro-open BEGIN_MESSAGE_MAP`
|
|
|
|
# `macro-close END_MESSAGE_MAP`
|
|
|
|
#
|
|
|
|
#
|
2020-06-14 12:02:19 -04:00
|
|
|
# option(s) with 'not default' value: 67
|
tools/codeformat.py: Add formatter using uncrustify for C, black for Py.
This commit adds a tool, codeformat.py, which will reformat C and Python
code to fit a certain style. By default the tool will reformat (almost)
all the original (ie not 3rd-party) .c, .h and .py files in this
repository. Passing filenames on the command-line to codeformat.py will
reformat only those. Reformatting is done in-place.
uncrustify is used for C reformatting, which is available for many
platforms and can be easily built from source, see
https://github.com/uncrustify/uncrustify. The configuration for uncrustify
is also added in this commit and values are chosen to best match the
existing code style. A small post-processing stage on .c and .h files is
done by codeformat.py (after running uncrustify) to fix up some minor
items:
- space inserted after * when used as multiplication with sizeof
- #if/ifdef/ifndef/elif/else/endif are dedented by one level when they are
configuring if-blocks and case-blocks.
For Python code, the formatter used is black, which can be pip-installed;
see https://github.com/psf/black. The defaults are used, except for line-
length which is set at 99 characters to match the "about 100" line-length
limit used in C code.
The formatting tools used and their configuration were chosen to strike a
balance between keeping existing style and not changing too many lines of
code, and enforcing a relatively strict style (especially for Python code).
This should help to keep the code consistent across everything, and reduce
cognitive load when writing new code to match the style.
2020-02-13 19:42:44 -05:00
|
|
|
#
|
|
|
|
|
|
|
|
# Custom types for MicroPython
|
|
|
|
type uint qstr
|