2 ms·
I’ve worked at a couple companies that had custom clang-tidy checks. This is well-documented enough at this point, but it is still a bit arcane. http://bbannie
by klodolph 5y ago
I’ve worked at a couple companies that had custom clang-tidy checks. This is well-documented enough at this point, but it is still a bit arcane.
http://bbannier.github.io/blog/2015/05/02/Writing-a-basic-clang-static-analysis-check.html http://bbannier.github.io/blog/2015/05/02/Writing-a-basic-cl...
Yes, it involves forking. Forking isn’t that big a deal. We even had checks that were specific to internal libraries.
- andi999 5y agoAt the start forking is like no deal at all. But how do you get new clang tidy features from the main branch later into your fork; I think this is the only instance which I would really call technical debt.
- klodolph 5y ago“Git pull” works pretty well to bring new clang-tidy features downstream. If you write a custom check, it goes in its own set of files, so there will be no merge conflicts. The only thing that would break is when the internal clang-tidy API changes, but clang-tidy checks tend to be fairly short. Really… I have worked at two companies that had extended clang-tidy to add custom checks for their code base. The whole point of clang-tidy is to automate code fixes in other parts of your code base. When done well, use of clang-tide pays down technical debt faster rather than adding to it.
- plorkyeran 5y agoForking to add new checks only causes problems with pulling from upstream when APIs you are using are changed upstream, which happens rarely. Forking to _modify_ existing checks would cause you a lot of pain, but the solution there is to copy the existing check instead.