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

[Brian Paul]

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