On 05/21/2015 05:05 PM, Rogovin, Kevin wrote:
This line is too long. (It will not fit in 80 columns in git log since git log
adds some spaces before each commit message line.)
What is the accepted maximum length for a line in a commit message?
Probably 75 chars since there's 4 spaces of indenting and we try to make
things look nice for 80-column terminals and editors.
- extension table
- additions to gl_framebuffer
v1 -> v2
Spacing and trailing spaces fixes.
This looks odd to me. I think you only need 'v2:' here. So, either
I have seen a number of patches with the notation v1 -> v2 to list changes between
versions. Those patches that I saw using that notation did not have comments about using
the format v1->v2. If people want v2: instead of v1->v2, I am fine with it, but
was just following what I saw in some patch series.
Given the number of nits around (that I seem to hit regularly), it might be
beneficial for Mesa to have a short document listing the formatting
requirements, of which I have so far collected:
1. 80 column limit in source files
2. Justify comments to 80 columns as well
Or 78 columns, to be safe, but there's exceptions, like if you're
defining a big static table/array of info.
3. comparison expressions require spaces around both sides of comparison
operator
Generally, a space on both sides of an operator like +, *, /, <, >=, etc.
4. successive parenthesis must have spaces between parenthesis
Example?
5. git commit messages have limit of N characters per line (the value of N I
am asking above).
75.
6. Use "whether condition" when describing a bool instead of "true if condition is
true"
not sure we care about that.
7. derived values of structs -should- be prefixed with an underscore (this
rule is loaded with exceptions in the code base from its evolution)
8. "indenting" is 3 spaces, except after switch where it is 0 (but after
case it is 3).
9. open bracket on same line
The 'indent' command in the docs should cover that.
10. no white spaces at end of line
11. functions for an extension must check if extension is supported and if
not emit an INVALID_OPERATION message instead of relying on function table
dispatch to guarantee they are not called.
Not sure about that, but that's not a coding style standard.
12. (Guessing here) consecutive empty lines are not allowed
Generally true, except between functions.
13. If changing a line that violates the nit rules, fix the line too rather
than just adding the change
Yeah, probably.
I suspect there are more as I listen to the nits, I think it might be
beneficial to collect all the formatting nits and write them down to the coding
standard thing in Mesa so that others can refer to it. Especially useful for
those that work on multiple projects with different coding standards.
Feel free to submit a patch against docs/devinfo.html with this info. :)
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
