-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add C++ style guidelines. #15
Conversation
For a starter commit, just adding the internal docs that we already have in research-software-documentation/processes/programming_projects/group_practices.md
Solves #6.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Should strongly consider ccache for medium to large projects. |
But that is tool, and not a style guide or something to check coding complies to a standard. So it's definitely out of scope for this PR and, I claim, out of scope for this repo. UCL-ARC/coding-standards is just coding standards. If we decide that we need a C++ equivalent of our UCL-ARC/python-tooling template and docs, then that'd be the place for it. But that's a moderate undertaking. |
OK updated my proposal in 82e92a8 to fall back to ISO core, based on the discussion here. Opted not to add an exception for I also spotted an English bug or two. |
Co-authored-by: Christian Gutschow <[email protected]>
Co-authored-by: Milan Malfait <[email protected]>
Are there any objections to this? At least as a starting point. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO worth getting this in and iterating on it if people have strong opinions
Includes and expands on our internal documentation.
I stuck with Google style because that was in our internal docs and it's what I know and like. If we have a consensus to switch to... something else... I'm fine with that.Edit: style tweaked based on discussion 👇
My opinion is: that we should have a decision that most of us agree with. I don't actually have a very strong opinion about which style to choose.
From the many many possible tools I have stuck to a single linter (
clang-tidy
) which is also what we discuss in PHAS0100, andcppcheck
as a single static analyser. Perhaps obviously, I want to avoid tools that no one in ARC has used or has experience with. We can add to them if we find something that is life-changing.@mmcleod89: following our IRL chat a couple of weeks ago, there's now some explanation of these guidelines' scope in the top-level README. Anyone who often works in C++ and has an opinion is welcome to join the review. The starting reviewers are C++istas that I've spoken to about this.
Solves