[Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

[Matt Turner]

On Thu, May 21, 2015 at 5:05 PM, Rogovin, Kevin <kevin.rogovin at intel.com> 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?

Gentoo's default vim configuration line wraps the commit message at 72
(I think because 72 + an 8-space tab in git log fits in an 80 column
window). It also changes the highlighting of the commit title itself
after 50 characters. I think both of those are reasonable, although
staying in 50 characters for the title is sometimes hard.

>
>>>  - 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
>  3. comparison expressions require spaces around both sides of comparison operator
>  4. successive parenthesis must have spaces between parenthesis
>  5. git commit messages have limit of N characters per line (the value of N I am asking above).
>  6. Use "whether condition" when describing a bool instead of "true if condition is true"
>  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
>  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.
>  12. (Guessing here) consecutive empty lines are not allowed
>  13. If changing a line that violates the nit rules, fix the line too rather than just adding the change
>
> 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.

I suppose it could be useful, but I think we've been mostly successful
at just expecting people to recognize when what they're writing
doesn't look like the code around it.