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

Rogovin, Kevin 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

> Example?

if (some_func(some_argument)) 

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

Yeah, probably.

> 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 mailing list