REmerald
commented
1 year ago Also, might be a good idea to add compile_commands.json (see details), so that LSPs (e.g. clangd, see the link above) and linters (e.g. solarlint) (inside Neovim or VSCode) can work and help find errors for the contributors.
You can generate it using bear, see the first link and the project page. It must be regenerated when the compilation/linking flags are changed to any of the source/object. But I think the best way to handle the file in the project is to regenerate it each time the changes to makefile are made, or when the new sources are added, just in case. Btw, there's also an interesting alternative compiledb.
Ok, it turns out, some projects are removing compile_flags.json, and I don't know why... But some of the big projects (see in makefiles of ibm-s390-linux/s390-tools, raspberrypi/linux) have the rules to generate them. So, you can add a rule, if you use the compile_command.json yourself. Regardless if you'll do it or not, it will be a good idea to add the file to .gitignore like here; and, btw, maybe negate .clang-format, like here?
Add
.clang-formatto the root of the project. See the details.Firstly, it automatically fixes the format mistakes (e.g. see
main.chere and here).Secondly, and most importantly, it tells the contributors the code style they should follow. Even if a contributor doesn't use clang-format, they can just read the
.clang-formatand learn the project style. And, if a contributor does use clang-format, they won't even have to be bothered with the style, because clang-format can just format the code according to the desired style.You don't even have to write the file from scratch, instead you can just copy the configuration from the project (but make sure not to break its license) that follows the same/similar coding style and tweak/add/remove some option according to your preference, and voila!