Tools or ideas on how to arrange different code formattings for different people

问题

I am looking for a way to put an end to "holy wars" about "the only right code formatting for all people". Currently, most companies have its own code-style (expressed as, for example, .clang-format), but obviously people have different mindsets/tastes/views on how the ideal formatting should look like.

My idea is based upon the fact that it is only important to push my code in central repo in the format of a company, while nobody prevents me from having and working with code that is formatted in my own way.

My question

Are there any tools (or a description of a workflow) that would allow me to have two differently formatted versions of source-code?

I suppose there should be something about scripts/local hooks and two git repos (one for officially formatted code, and one for my version)? Or alternatively, it might be possible to have just one repo and reformat the code on commit, but disadvantage of the approach is that IDE's diff will not work (well, it will, but it will show huge code diffs all the time).

回答1:

Are there any tools (or a description of a workflow) that would allow me to have two differently formatted versions of source-code?

As commented, using a common convention is easier.
For example, any program written in Go would use go fmt, included with the language itself.

But yes, you can locally define a Git content filter driver which will:

^{(image from "Customizing Git - Git Attributes", from "Pro Git book")}

• automatically apply your format to your code on checkout
• automatically apply the company format to your code on commit

The diff will be preserved.

The content filter driver will only apply to files with a certain extension, as define in a .gitattributes file.

But it will be activated in a local Git configuration

---

You can find an example of that approach in the project prettier/prettier, in issue issue 129:

For projects that use prettier, developers who prefer a different prettier config could configure git smudge/clean filters to do this for them, without having to involve editors.
For example, putting this into .git/config:

[filter "prettier"]
 clean = prettier --stdin --no-semi --single-quote
 smudge = prettier --stdin

and putting this into .git/info/attributes:

*.js filter=prettier

makes it so that files are checked into the repository with single quotes and without semicolons, but are checked out onto the disk with double quotes and semicolons.

回答2:

Thank you @VonC,

Here I just wanted to post a quick and ready to use implementation of your idea with Git content filter driver.

In .git/config add

[filter "clangformat"]
    smudge = .git/clang-formatter.sh .clang-format-my
    clean = .git/clang-formatter.sh .clang-format-company

Explanation:

• smudge - the command that is called when you pull something (more precisely when git checks sources out onto your disk)
• clean - the command that is called when you push something (more precisely when you add files in the git's staging area).
• .clang-format-my and .clang-format-company - self-explanatory clang-format files.

.git/clang-formatter.sh is a small script that invokes clang-format. The main purpose of the script is to "prepare" value for -style option (via awk):

#!/bin/bash

clang-format-8 -style "{$(awk '{if ($0 !~ /#/) {if (NR>1) {printf ", "} printf $0; }}' $1)}" -assume-filename=main.cpp

• clang-format-8 - clang-format itself, remove the version or verify it is correct
• awk script converts contents of .clang-format-my (or .clang-format-company) into inline format: -style "{Option1: Value, ...}", because there is no way to specify filename with config to clang-format
• do not forget to make the script executable: chmod +x .git/clang-formatter.sh

In .git/info/ add attributes file:

*.c filter=clangformat
*.h filter=clangformat
*.cpp filter=clangformat
*.hpp filter=clangformat

Note, that clangformat in the attributes must match to [filter "clangformat"] in in .git/config.

来源：https://stackoverflow.com/questions/59335932/tools-or-ideas-on-how-to-arrange-different-code-formattings-for-different-people