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

Jason Wilkins jason.a.wilkins at gmail.com
Sun May 6 08:11:10 CEST 2012


Yes, there are two different points here:

First, Existing identifiers that are named glBlahBlah should be
renamed to blah_blah_gl so that their is no confusion.

Second, an identifier that is GL related but is currently named
blah_blah should be renamed blah_blah_gl.

I agree that this should not be done simply so that a tool is easier
to write.  I was going to try and reiterate my justifications, but
honestly this just satisfies my own personal desire for consistency
:-)

Besides, an argument could be made that regular expressions are a
dumb, but useful tool, and following a convention that allows you to
use them fearlessly is probably a good thing.

On Sat, May 5, 2012 at 9:09 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list