C/C++ style guide #7
Conversation
- Wrote C/C++ style guide rules.
- Added links
- Fixed line
- Made some correctness of lines
- Fix size of See Also
- Fix typo
|
It's pretty good, but a little too reliant on 'read these books for
guidance'. I'd rather filter out a few pieces of guidance as precise
help. Things we discussed about error handling, clarity of comments, etc.
should be listed there.
…On Fri, Apr 14, 2017 at 11:58 PM, Artyom Baloyan ***@***.***> wrote:
@baloyan <https://github.com/baloyan> requested your review on:
secure-systems-lab/code-style-guidelines#7
<#7>
C/C++ style guide.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XDyYALiYpD47kMTjjQaSvUMcDTEZmks5rwEB4gaJpZM4M-Pgq>
.
|
|
Actually books are not directly related to style guide, though most of security style guide rules were taken from Mayer's books. The idea is that to provide resources in order to became more professional developer in C/C++. It is not necessary, but it is good practice. What do you think @JustinCappos ? May would be better to change a title little bit instead of saying just See Also ? Things about error handling, clarity of comments, etc Google style guide provides. For example, I just put here one line "Do not state the obvious. In particular, don't literally describe what code does, unless the behavior is non-obvious to a reader who understands C++ well. Instead, provide higher level comments that describe why the code does what it does, or make the code self describing." Do you think it is not enough ? |
|
More of that kind of wisdom from the discussions is helpful.
…On Sat, Apr 15, 2017 at 1:19 PM, Artyom Baloyan ***@***.***> wrote:
Actually books are not directly related to style guide, besides most of
security style guide rules were taken from Mayer's books. The idea is that
to provide resources in order to became more professional developer in
C/C++. It is not necessary, but it is good practice. What do you think
@JustinCappos <https://github.com/JustinCappos> ? May would be better to
change a title little bit instead of saying just See Also ?
Things about error handling, clarity of comments, etc Google style guide
provides. For example, I just put here one line
"Do not state the obvious. In particular, don't literally describe what
code does, unless the behavior is non-obvious to a reader who understands
C++ well. Instead, provide higher level comments that describe why the code
does what it does, or make the code self describing."
Do you think it is not enough ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XDyh05Fzadhu3UUtyYjd511j3Itcfks5rwPwEgaJpZM4M-Pgq>
.
|
|
Are there guidelines in Google's C++ doc that we might want to modify or explain further? For example, Google's guideline on vertical whitespace differs a bit with the one we follow for Python, where we advise developers to separate top-level functions with at least 5 blank lines. In contrast, Google's doc simply says to minimize vertical whitespace. We should also cover, in our doc, some of the more important guidelines. What about topics not covered in Google's guidelines? Although not really a style guide, how should we handle testing? Do we want to use the same testing framework across all projects? How should developers write a function and their tests? |
|
I am not sure that it is a good idea to change something in Google Style Guide, because we follow the same rules in Python in a different way and in general I think it would be better not to compare C/C++ with Python, just let's see it is as a C/C++ language (Joke: let's think like a compiler not like an interpreter). I will check that topics is not covered in Google's guideline that we have in our current guidelines and let you know. |
|
I'm happier with our vertical whitespace rules, but want to hear what
others think.
Philosophically, I don't think we should fixate too heavily on what is
recommended by others. If we feel there is a good enough reason to change,
we should do so.
…On Wed, Apr 19, 2017 at 10:18 AM, Vladimir Diaz ***@***.***> wrote:
Are there guidelines in Google's C++ doc that we might want to modify or
explain further? For example, Google's guideline on vertical whitespace
<https://google.github.io/styleguide/cppguide.html#Vertical_Whitespace>
differs a bit with the one we follow for Python, where we advise developers
to separate top-level functions with at least 5 blank lines. In contrast,
Google's doc simply says to minimize vertical whitespace.
We should also cover, in our doc, some of the more important guidelines.
What about topics not covered in Google's guidelines? Although not really a
style guide, how should we handle testing? Do we want to use the same
testing framework across all projects? How should developers write a
function and their tests?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XD_IxQq36QHbIoH15HAnbsPHwt8zNks5rxhfNgaJpZM4M-Pgq>
.
|
|
The idea/reason is to keep Google style guide as it is, but if would like to add some other extra rules which Google style guide does not contain let's do it, like we did with security rules. |
|
Sure, we've always lightly modified other style guides. This will be no
exception.
…On Wed, Apr 19, 2017 at 12:37 PM, Artyom Baloyan ***@***.***> wrote:
The idea/reason is to keep Google style guide as it is, but if would like
to add some other extra rules which Google style guide does not contain
let's do it, like we did with security rules.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XD-Cy0JfVVD-K90y64ri2lQYEtRxTks5rxjhEgaJpZM4M-Pgq>
.
|
|
I prefer vertical whitespace between functions/classes |
|
So do I! |
|
Okay, so I think we will make this change. Let's propose others as they
come up.
…On Wed, Apr 19, 2017 at 12:58 PM, aaaaalbert ***@***.***> wrote:
So do I!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XD3ZMLhHz-7h3bOtW7woERJ-bKZFGks5rxj0mgaJpZM4M-Pgq>
.
|
|
I'm a little bit skeptical about adding the Google C++ guideline in certain cases, I'd disambiguate claims like these: As they seem to be completely opposite to what we suggest in other guidelines. |
|
I agree that this should be overridden.
Should we have started from a different ruleset? Is there an easy way to
choose what to keep / toss?
For most rules, they likely will never come up, so I'd like to avoid
spending time on them, if possible.
Justin
…On Fri, Apr 21, 2017 at 5:17 PM, Santiago Torres ***@***.***> wrote:
I'm a little bit skeptical about adding the Google C++ guideline in
certain cases, I'd disambiguate claims like these:
Classes are the fundamental unit of code in C++. Naturally, we use them extensively.
As they seem to be completely opposite to what we suggest in other
guidelines.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XDxV_if0OeniCiLyqPoukAaASydeiks5ryRzhgaJpZM4M-Pgq>
.
|
C/C++ style guide for Secure Systems Lab.
Added C++_Style_Guide.md file.
Wrote C/C++ style guide
Please have a look and write a comments.