mirror of https://gitee.com/openkylin/linux.git
185 lines
6.4 KiB
ReStructuredText
185 lines
6.4 KiB
ReStructuredText
|
.. _clangformat:
|
||
|
|
||
|
clang-format
|
||
|
============
|
||
|
|
||
|
``clang-format`` is a tool to format C/C++/... code according to
|
||
|
a set of rules and heuristics. Like most tools, it is not perfect
|
||
|
nor covers every single case, but it is good enough to be helpful.
|
||
|
|
||
|
``clang-format`` can be used for several purposes:
|
||
|
|
||
|
- Quickly reformat a block of code to the kernel style. Specially useful
|
||
|
when moving code around and aligning/sorting. See clangformatreformat_.
|
||
|
|
||
|
- Spot style mistakes, typos and possible improvements in files
|
||
|
you maintain, patches you review, diffs, etc. See clangformatreview_.
|
||
|
|
||
|
- Help you follow the coding style rules, specially useful for those
|
||
|
new to kernel development or working at the same time in several
|
||
|
projects with different coding styles.
|
||
|
|
||
|
Its configuration file is ``.clang-format`` in the root of the kernel tree.
|
||
|
The rules contained there try to approximate the most common kernel
|
||
|
coding style. They also try to follow :ref:`Documentation/process/coding-style.rst <codingstyle>`
|
||
|
as much as possible. Since not all the kernel follows the same style,
|
||
|
it is possible that you may want to tweak the defaults for a particular
|
||
|
subsystem or folder. To do so, you can override the defaults by writing
|
||
|
another ``.clang-format`` file in a subfolder.
|
||
|
|
||
|
The tool itself has already been included in the repositories of popular
|
||
|
Linux distributions for a long time. Search for ``clang-format`` in
|
||
|
your repositories. Otherwise, you can either download pre-built
|
||
|
LLVM/clang binaries or build the source code from:
|
||
|
|
||
|
http://releases.llvm.org/download.html
|
||
|
|
||
|
See more information about the tool at:
|
||
|
|
||
|
https://clang.llvm.org/docs/ClangFormat.html
|
||
|
|
||
|
https://clang.llvm.org/docs/ClangFormatStyleOptions.html
|
||
|
|
||
|
|
||
|
.. _clangformatreview:
|
||
|
|
||
|
Review files and patches for coding style
|
||
|
-----------------------------------------
|
||
|
|
||
|
By running the tool in its inline mode, you can review full subsystems,
|
||
|
folders or individual files for code style mistakes, typos or improvements.
|
||
|
|
||
|
To do so, you can run something like::
|
||
|
|
||
|
# Make sure your working directory is clean!
|
||
|
clang-format -i kernel/*.[ch]
|
||
|
|
||
|
And then take a look at the git diff.
|
||
|
|
||
|
Counting the lines of such a diff is also useful for improving/tweaking
|
||
|
the style options in the configuration file; as well as testing new
|
||
|
``clang-format`` features/versions.
|
||
|
|
||
|
``clang-format`` also supports reading unified diffs, so you can review
|
||
|
patches and git diffs easily. See the documentation at:
|
||
|
|
||
|
https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
|
||
|
|
||
|
To avoid ``clang-format`` formatting some portion of a file, you can do::
|
||
|
|
||
|
int formatted_code;
|
||
|
// clang-format off
|
||
|
void unformatted_code ;
|
||
|
// clang-format on
|
||
|
void formatted_code_again;
|
||
|
|
||
|
While it might be tempting to use this to keep a file always in sync with
|
||
|
``clang-format``, specially if you are writing new files or if you are
|
||
|
a maintainer, please note that people might be running different
|
||
|
``clang-format`` versions or not have it available at all. Therefore,
|
||
|
you should probably refrain yourself from using this in kernel sources;
|
||
|
at least until we see if ``clang-format`` becomes commonplace.
|
||
|
|
||
|
|
||
|
.. _clangformatreformat:
|
||
|
|
||
|
Reformatting blocks of code
|
||
|
---------------------------
|
||
|
|
||
|
By using an integration with your text editor, you can reformat arbitrary
|
||
|
blocks (selections) of code with a single keystroke. This is specially
|
||
|
useful when moving code around, for complex code that is deeply intended,
|
||
|
for multi-line macros (and aligning their backslashes), etc.
|
||
|
|
||
|
Remember that you can always tweak the changes afterwards in those cases
|
||
|
where the tool did not do an optimal job. But as a first approximation,
|
||
|
it can be very useful.
|
||
|
|
||
|
There are integrations for many popular text editors. For some of them,
|
||
|
like vim, emacs, BBEdit and Visual Studio you can find support built-in.
|
||
|
For instructions, read the appropiate section at:
|
||
|
|
||
|
https://clang.llvm.org/docs/ClangFormat.html
|
||
|
|
||
|
For Atom, Eclipse, Sublime Text, Visual Studio Code, XCode and other
|
||
|
editors and IDEs you should be able to find ready-to-use plugins.
|
||
|
|
||
|
For this use case, consider using a secondary ``.clang-format``
|
||
|
so that you can tweak a few options. See clangformatextra_.
|
||
|
|
||
|
|
||
|
.. _clangformatmissing:
|
||
|
|
||
|
Missing support
|
||
|
---------------
|
||
|
|
||
|
``clang-format`` is missing support for some things that are common
|
||
|
in kernel code. They are easy to remember, so if you use the tool
|
||
|
regularly, you will quickly learn to avoid/ignore those.
|
||
|
|
||
|
In particular, some very common ones you will notice are:
|
||
|
|
||
|
- Aligned blocks of one-line ``#defines``, e.g.::
|
||
|
|
||
|
#define TRACING_MAP_BITS_DEFAULT 11
|
||
|
#define TRACING_MAP_BITS_MAX 17
|
||
|
#define TRACING_MAP_BITS_MIN 7
|
||
|
|
||
|
vs.::
|
||
|
|
||
|
#define TRACING_MAP_BITS_DEFAULT 11
|
||
|
#define TRACING_MAP_BITS_MAX 17
|
||
|
#define TRACING_MAP_BITS_MIN 7
|
||
|
|
||
|
- Aligned designated initializers, e.g.::
|
||
|
|
||
|
static const struct file_operations uprobe_events_ops = {
|
||
|
.owner = THIS_MODULE,
|
||
|
.open = probes_open,
|
||
|
.read = seq_read,
|
||
|
.llseek = seq_lseek,
|
||
|
.release = seq_release,
|
||
|
.write = probes_write,
|
||
|
};
|
||
|
|
||
|
vs.::
|
||
|
|
||
|
static const struct file_operations uprobe_events_ops = {
|
||
|
.owner = THIS_MODULE,
|
||
|
.open = probes_open,
|
||
|
.read = seq_read,
|
||
|
.llseek = seq_lseek,
|
||
|
.release = seq_release,
|
||
|
.write = probes_write,
|
||
|
};
|
||
|
|
||
|
|
||
|
.. _clangformatextra:
|
||
|
|
||
|
Extra features/options
|
||
|
----------------------
|
||
|
|
||
|
Some features/style options are not enabled by default in the configuration
|
||
|
file in order to minimize the differences between the output and the current
|
||
|
code. In other words, to make the difference as small as possible,
|
||
|
which makes reviewing full-file style, as well diffs and patches as easy
|
||
|
as possible.
|
||
|
|
||
|
In other cases (e.g. particular subsystems/folders/files), the kernel style
|
||
|
might be different and enabling some of these options may approximate
|
||
|
better the style there.
|
||
|
|
||
|
For instance:
|
||
|
|
||
|
- Aligning assignments (``AlignConsecutiveAssignments``).
|
||
|
|
||
|
- Aligning declarations (``AlignConsecutiveDeclarations``).
|
||
|
|
||
|
- Reflowing text in comments (``ReflowComments``).
|
||
|
|
||
|
- Sorting ``#includes`` (``SortIncludes``).
|
||
|
|
||
|
They are typically useful for block re-formatting, rather than full-file.
|
||
|
You might want to create another ``.clang-format`` file and use that one
|
||
|
from your editor/IDE instead.
|