A bit more precise InnoDB style:

UseTab: Always

TabWidth: 8

IndentWidth: 8

BreakBeforeBinaryOperators: NonAssignment

PointerAlignment: Left

AlwaysBreakAfterReturnType: TopLevel

BinPackParameters: true

ContinuationIndentWidth: 8

BreakBeforeBraces: Custom

BraceWrapping:

  AfterFunction: true

Some scripts like integration with IDE, git-clang-format, clang-format-diff: https://github.com/llvm-mirror/clang/tree/master/tools/clang-format

The task itself is rather questionable: "Make use of clang-format". Why it should be used? The goal should be paramaunt but not the instrument. If the task is about increasing productivity, then how it helps achieving it?

As I see from the video it is just a very intelligent formatter, like crustify, but maybe better. But not more: it won't do things beyond formatting and this is rather minor part of productivity.

Using auto-formatters without human control in scope of VCS is also questionable: formatting garbles history. It may touch the lines that should not be touched by a patch.

Machine formatting even very smart is impossible to handle 100% of cases to supply good readability. While it induces lazyness, like "everything is under coding style conditions" it produces something like this:

  if (thd->work_part_info &&

      !(create_info->db_type->flags & HTON_NATIVE_SYS_VERSIONING) &&

      thd->work_part_info->default_engine_type &&

      (thd->work_part_info->default_engine_type->flags &

       HTON_NATIVE_SYS_VERSIONING))

Is it readable? I wouldn't say so. Is it productive? While I try to read this code and modify it to be more readable I spend efforts which makes it not very productive.

How it can help to be productive? I see it as a series of config files in src trees `sql/`, `storage/innodbase`, etc. Where developer may (but not must) use it as a helping aid to do local formatting (as there are different coding styles in different subtrees). This conception is not different from .editorconfig, .kateconfig, etc which are good helping aid to apply correct editor settings. See info on editorconfig.

root = true

[*]

end_of_line = lf

insert_final_newline = true

trim_trailing_whitespace = false

[Makefile]

indent_style = tab

[*]

indent_style = space

indent_size = 2

tab_width = 8

[*]

indent_style = tab

indent_size = tab

tab_width = 8

end_of_line = lf

insert_final_newline = true

trim_trailing_whitespace = false

These files should be also in source tree along with auto-formatter configs.

Let's have proposed patch as a starting point. I read a bit about editorconfig, clang-format seems to be superior. Comments like "I loved EditorConfig until tools like clang-format and gofmt showed up" don't seem to be uncommon.

My point is: it's not important what tool to use. There can be many configs for many tools for different goals. The editorconfig is an example of tool that applies config to your editor depending on file location. This is not a replacement for clang-format of course.