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

[Jason Wilkins]

I think we agree.  My definition of "related" is not infectious.  Even
"draw_something" is not really gl related in my definition.

It would only be for public identifiers (struct members, extern
functions) which either directly hold gl types or perform very gl
specific functions.  For example, just drawing something is not gl
related in my view, but managing extensions is.  In other words, it is
the difference between "using" and "wrapping" the gl (does that make
sense?).

And for local variable names (including parameter names), you are
right, there is no need.  A public function that took a GLuint would
probably already be named something_gl in my scheme.  If it was a
static function however, it could still just be named "something".



On Sun, May 6, 2012 at 3:49 PM, Mike Erwin <significant.bit at gmail.com> wrote:
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers