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

[Mike Erwin]

Hey Jason,

I agree that glBlah, gl_blah, GLblah, and GL_BLAH look too much like
"official" OpenGL/GLSL and should be avoided or renamed to avoid
confusion. Not so sure about tacking _gl at the end of anything
related. For the support functions & types you'll be building this
summer, absolutely. A function that abstracts OpenGL calls could be
named draw_something_gl, and that makes sense. Functions that call
draw_something_gl but don't use the OpenGL API directly should not
have a _gl suffix. Functions & types should have to earn this suffix,
so to speak.

For variable names, no thanks! For clarity I try to use the GL types
(GLfloat, etc.) even though they're just simple typedefs. But I name
that GLfloat variable whatever makes sense in context to what's around
it.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


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