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

[Campbell Barton]

If I understand correctly youd like to reduce confusion so
glBlahBlah isnt confused with SomeBlenderStruct.glBlahBlah, instead
using different convention of SomeBlenderStruct.gl_blah_blah

While Im not wary of changing code simply so some regex tools can
parse it easier, I think this is reasonable to avoid confusion, IMHO
it makes it more readable for humans too :)

In fact for our C and python code we have loose convention of camel
case for types and underscores for members/attributes, so this is in
keeping with our current style guide even.

On Sat, May 5, 2012 at 2:57 PM, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:
> 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 :-)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell