List of options

Align

Note: only few of "align_*" options really work, all other are bugged.

• align_keep_tabs: Whether to keep non-indenting tabs.
• align_right_cmt_at_col: Minimum column at which to align trailing comments.
• align_right_cmt_gap: Minimum number of columns between preceding text and a trailing comment in order for the comment to qualify for being aligned.
• align_right_cmt_span: The span for aligning comments that end lines.
• align_same_func_call_params: Whether to align parameters in single-line functions that have the same name.
• align_same_func_call_params_span: The span for aligning function-call parameters for single line functions.
• align_var_def_amp_style: How to consider (or treat) the '&' in the alignment of variable definitions.
• align_var_def_colon: Whether to align the colon in struct bit fields.
• align_var_def_inline: Whether to align inline struct/enum/union variable definitions.
• align_var_def_span: The span for aligning variable definitions.
• align_var_def_star_style: How to consider (or treat) the '*' in the alignment of variable definitions.

Spacing

• sp_after_assign: Add or remove space after assignment operator '=', '+=', etc.
• sp_after_semi: Add or remove space after ;, except when followed by a comment.
• sp_after_semi_for: Add or remove space after ; in non-empty for statements.
• sp_angle_paren
• sp_angle_paren_empty
• sp_angle_shift
• sp_angle_word
• sp_assign: Add or remove space around assignment operator '=', '+=', etc.
• sp_balance_nested_parens: Whether to balance spaces inside nested parentheses.
• sp_before_assign: Add or remove space before assignment operator '=', '+=', etc.
• sp_before_sparen: Add or remove space before ( of control statements (if, for, switch, while etc.).
• sp_before_tr_emb_cmt: Add or remove space before a trailing or embedded comment.
• sp_brace_catch: Add or remove space between '}' and 'catch' if on the same line.
• sp_brace_else: Add or remove space between } and else if on the same line
• sp_catch_brace: 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_paren: Add or remove space between catch and ( in catch (something) { }. If set to ignore, sp_before_sparen is used.
• sp_cpp_lambda_assign
• sp_cpp_lambda_paren
• sp_else_brace
• sp_inside_angle
• sp_inside_fparens
• sp_not
• sp_num_before_tr_emb_cmt: Number of spaces before a trailing or embedded comment.
• sp_permit_cpp11_shift
• sp_try_brace: Add or remove space between try and { if on the same line.

Indent

• align_left_shift: Whether to align lines that start with '<<' with previous '<<'.
• indent_access_spec: Same as indent_label, but for access specifiers that are followed by a colon.
• indent_access_spec_body: Whether to indent the code after an access specifier by one level.
• indent_align_assign: Whether to align continued statements at the '='. If false or if the '=' is followed by a newline, the next line is indent one tab.
• indent_align_string: Whether to indent strings broken by '\' so that they line up.
• indent_brace_parent: Whether to indent based on the size of the brace parent.
• indent_braces: Whether braces are indented to the body level.
• indent_braces_no_func: Whether to disable indenting function braces if indent_braces=true.
• indent_braces_no_class: Whether to disable indenting class braces if indent_braces=true.
• indent_braces_no_struct: Whether to disable indenting struct braces if indent_braces=true.
• indent_class: Whether the 'class' body is indented.
• indent_class_colon: Whether to indent the stuff after a leading base class colon.
• indent_class_on_colon: Whether to indent based on a class colon instead of the stuff after the colon.
• indent_col1_comment: Whether to indent comments found in first column.
• indent_columns: The number of columns to indent per level.
• indent_continue: The continuation indent. If non-zero, this overrides the indent of '(', '[' and '=' continuation indents.
• indent_constr_colon: Whether to indent the stuff after a leading class initializer colon.
• indent_comma_paren: Whether to indent a comma when inside a parenthesis. If true, aligns under the open parenthesis.
• indent_ctor_init_leading: Virtual indent from the ':' for member initializers.
• indent_else_if: Whether to indent if following else as a new block under the else.
• indent_extern: Whether the extern "C" body is indented.
• indent_first_for_expr: Whether to align the first expression to following ones if indent_semicolon_for_paren=true.
• indent_func_call_param: Whether to indent continued function call parameters one indent level, rather than aligning parameters under the open parenthesis.
• indent_func_class_param: Same as indent_func_def_param, but for class declarations.
• indent_func_ctor_var_param: Same as indent_func_def_param, but for class variable constructors.
• indent_func_def_param: Same as indent_func_call_param, but for function definitions.
• indent_func_param_double: Double the indent for indent_func_xxx_param options. Use both values of the options indent_columns and indent_param
• indent_func_proto_param: Same as indent_func_call_param, but for function prototypes.
• indent_namespace: Whether to indent the body of a 'namespace'.
• indent_param: The continuation indent for func_*_param if they are true. If non-zero, this overrides the indent.
• indent_paren_close: How to indent a close parenthesis after a newline.
• indent_paren_nl: If an open parenthesis is followed by a newline, whether to indent the next line so that it lines up after the open parenthesis.
• indent_relative_single_line_comments: Whether to indent trailing single line ('//') comments relative to the code instead of trying to keep the same absolute column.
• indent_semicolon_for_paren: Whether to indent a semicolon when inside a for parenthesis.
• indent_shift: Whether to indent continued shift expressions ('<<' and '>>') instead of aligning.
• indent_sing_line_comments: Spaces to indent single line (//) comments on lines before code.
• indent_square_nl: 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_template_param: Same as indent_func_def_param, but for template parameter lists.
• indent_with_tabs: How to use tabs when indenting code.
• indent_xml_string: The number of spaces to indent multi-line XML strings.

Newline

• nl_after_brace_open: Whether to add a newline after '{'. This also adds a newline before the matching '}'.
• nl_after_brace_open_cmt: Whether to add a newline between the open brace and a trailing single-line comment.
• nl_after_brace_close: Whether to add a newline after }. Does not apply if followed by a necessary ;.
• nl_after_case: Whether to add a newline after a case statement.
• nl_after_func_body: The number of newlines after '}' of a multi-line function body.
• nl_after_func_body_one_liner: The number of newlines after '}' of a single line function body.
• nl_after_if: Add or remove blank line after 'if' statement.
• nl_after_multiline_comment: Whether to force a newline after a multi-line comment.
• nl_after_return: Whether to put a blank line after return statements, unless followed by a close brace.
• nl_after semicolon: Whether to add a newline after semicolons, except in for statements.
• nl_after_switch: Add or remove blank line after switch statement.
• nl_assign_leave_one_liners: Don't split one-line braced assignments, as in foo_t f = { 1, 2 };.
• nl_before_block_comment
• nl_before_case: Whether to add a newline before case, and a blank line before a case statement that follows a ; or }.
• nl_before_if: Add or remove blank line before 'if'.
• nl_before_switch: Add or remove blank line before switch statement.
• nl_brace_else: Add or remove newline between } and else.
• nl_catch_brace
• nl_collapse_empty_body: Whether to collapse empty blocks between '{' and '}'.
• nl_create_for_one_liner: Whether to remove a newline in simple unbraced for statements.
• nl_create_func_def_one_liner: 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_if_one_liner: Whether to remove a newline in simple unbraced if statements
• nl_create_while_one_liner: Whether to remove a newline in simple unbraced while statements
• nl_define_macro: Whether to alter newlines in #define macros.
• nl_ds_struct_enum_close_brace: Whether to force a newline before '}' of a 'struct'/'union'/'enum'.
• nl_ds_struct_enum_cmt: Whether to double-space commented-entries in 'struct'/'union'/'enum'.
• nl_else_brace
• nl_elseif_brace
• nl_enum_leave_one_liners: Don't split one-line enums, as in enum foo { BAR = 15 };.
• nl_fdef_brace: Add or remove newline between function signature and {.
• nl_for_brace: Add or remove newline between 'for' and '{'.
• nl_for_leave_one_liners: Don't split one-line for statements, as in for(...) b++;.
• nl_if_brace
• nl_if_leave_one_liners
• nl_max
• nl_max_blank_in_func
• nl_multi_line_cond
• nl_multi_line_define: Force a newline in a define after the macro name for multi-line defines.
• nl_squeeze_ifdef: Whether to remove blanks after #ifxx and #elxx, or before #elxx and #endif.
• nl_squeeze_ifdef_top_level: Makes the nl_squeeze_ifdef option affect the top-level #ifdefs as well.
• nl_switch_brace: Add or remove newline between 'switch' and '{'.

Other

• cmt_width
• code_width: Try to limit code width to N columns. Break line if it's too long.
• disable_processing_cmt: Specify the marker used in comments to disable processing of part of the file
• eat_blanks_after_open_brace: Whether to remove blank lines after {.
• eat_blanks_before_close_brace: Whether to remove blank lines before '}'
• enable_processing_cmt: Specify the marker used in comments to (re)enable processing in a file
• ls_code_width: Whether to split lines as close to code_width as possible and ignore some groupings.
• ls_for_split_full: Whether to fully split long 'for' statements at semi-colons.
• ls_func_split_full: Whether to fully split long function prototypes/calls at commas.
• mod_full_brace_if
• mod_full_brace_for
• mod_full_paren_if_bool: Whether to fully parenthesize Boolean expressions in 'while' and 'if' statement.
• mod_remove_extra_semicolon: Whether to remove superfluous semicolons.

Bugged options

Some options do not work (or are too sophisticated to understand how they work):

• align_right_cmt_at_col
• align_same_func_call_params_span
• align_var_def_amp_style
• align_var_def_inline
• align_var_def_colon
• indent_align_assign
• indent_braces_no_class
• indent_ctor_init_leading
• indent_first_for_expr
• indent_relative_single_line_comments
• indent_semicolon_for_paren
• indent_template_param
• nl_after_brace_close
• nl_after semicolon
• nl_assign_leave_one_liners
• nl_define_macro
• nl_ds_struct_enum_cmt
• nl_enum_leave_one_liners
• nl_for_leave_one_liners
• mod_full_paren_if_bool
• mod_remove_extra_semicolon