[Bf-committers] New Style Rule? (OpenGL Related)

Jason Wilkins jason.a.wilkins at gmail.com
Sat May 5 14:57:00 CEST 2012


I'd like to propose that if an identifier is used with OpenGL, and it
holds or implements something that is directly OpenGL related, that
its name should follow a convention that clearly marks it as OpenGL
related but is not mistakable for a proper OpenGL token.

I would suggest the _suffix style.  For example:

GLint texture_id_gl;

What would be wrong would be:

int gl_texture_id; /* Is this a GLSL token?? */

A real example in Blender is a variable named 'glxVersionMajor'.  My
suggestion would be version_major_glx (depending on what other
variables in GHOST look like).

My justification is two fold.

1) Although humans with lots of GL experience can tell a "fake" OpenGL
symbol from the thousands (literally) of real ones, novices and
automated tools cannot be certain.

2) The _suffix style appears to be the only set of tokens that OpenGL
*has not already used* /sigh.

On side note, I'm sure there are many variables containing OpenGL
values that are difficult to find because they do not follow any
convention, so they aren't even fake :-) (That is a reference to "not
even wrong").  Although there are only about 20 "fake" tokens now,
there may be hundreds of "not even fake" variables.  I see these are
low priority however, but I will probably rename them as I re-factor
OpenGL code this summer.

So, as a general question, what pitfalls do I need to look out for as
if I rename things in Blender?

The one thing I can think of is that I should be careful of DNA
structures.   Another is I should avoid areas where large merge
conflicts may occur.  Anything else?

Sorry if this seems trivial, but it is usually the trivial things that
you get in the most trouble for since everybody has an opinion :-)

I am currently putting together a "Blender OpenGL Programming Policy
and Style Guide", and I'd like to reach a consensus on what will be in
it before I get to the end of SoC and you all find out that I've
implemented it all behind your backs :-)


More information about the Bf-committers mailing list