[Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments
kevin.rogovin at intel.com
Thu May 21 17:26:16 PDT 2015
>Or 78 columns, to be safe, but there's exceptions, like if you're
> defining a big static table/array of info.
Uggg.... I don't mind exceptions, but knowing them is key.
>> 4. successive parenthesis must have spaces between parenthesis
is bad, but
if (some_func(some_argument) )
is good. I am also guessing that
a = foo(bar(x));
is bad and must be changed to
a = foo(bar(x) );
>> 6. Use "whether condition" when describing a bool instead of "true if condition is true"
> not sure we care about that.
I hit a nit for it in the series, so someone cared.
> 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.
> > 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.
Perhaps coding standard is not the right word, but it is a requirement (atleast it seems that way) and is a trivial requirement to satisfy.
>> 12. (Guessing here) consecutive empty lines are not allowed
> Generally true, except between functions.
Ugg... I hit a nit from an extra space between functions.
> 13. If changing a line that violates the nit rules, fix the line too rather than just adding the change
> Feel free to submit a patch against docs/devinfo.html with this info. :)
I do not mind submitting the patch, but I want to know what the rules are; preferably explicitly written rather than inferred (by me). Especially since I seem to hit nits like no tomorrow even when trying not to :)
More information about the mesa-dev