While you can build your clang-format configuration from scratch, it’s much easier to start with an existing style and make your modifications. Consider whether such a rule is ultimately important and enforce it in other ways. Appoint someone as the ultimate decision maker if there is no clear winner for a style guideline.Īlso, be aware that some style rules cannot be checked by the tool. Whether spaces or tabs are used is ultimately unimportant, and once a tool is impersonally updating everyone’s code it won’t matter at all. Don’t get dragged into unnecessary arguments. A list of style guides that you can refer to is found in the next section. You can use the handy programming style guide that your team has ignored, or you can review style guides and rules from around the web and decide which rules your team should adopt.
Thinking About Style Guidelinesīefore you begin this adventure, it’s important to have some style guidelines in mind for your team. Luckily, the clang team has created a wonderful tool that we can leverage: clang-format.īy using clang-format, we can create a list of style rules, enable programmers to quickly reformat their code, and create formatting checks that run on our build servers to ensure compliance. Instead of relying on programmers to follow a set of rules, we should automate the process to make it as simple and impersonal as possible. The MongoDB team has provided us with an excellent formatting principle:Ī formatting process which is both manual and insufficient is doomed to be abandoned. In almost every case the style guide is ignored, code reviews devolve into style arguments, and a multitude of styles develop inside of the source repository. I’ve worked on many programming teams which nominally have a “programming style guide.” This guide is often written down and placed in a place that developers rarely look.
0 kommentar(er)
