[Bf-committers] New Style Rule? (OpenGL Related)
jason.a.wilkins at gmail.com
Sun May 6 22:45:14 CEST 2012
Good tip on ignoring comments. I'm not sure if I should ignore them
completely though because a lot of what I found in comments could use
a correction (glSelect instead of GL_SELECT for example). Right now
it's not a problem.
On Sun, May 6, 2012 at 6:01 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> (correction to previous reply - "While I _AM_ wary of changing code
> simply so some regex tools can
> parse it easier...")
> gl_blah_blah vs blah_blah_gl, Im not that fussed --- perhaps other
> devs have an opinion but if you like to do the work to make this
> consistent in blenders code either is OK by me.
> on a side note - I recently found pygments tokenizer handy for
> something more powerful then regex but less trouble then parsing C/C++
> completely. - this way its easy to tell a comment or string from code
> - see source/tools/check_style_c.py for example usage.
> On Sun, May 6, 2012 at 8: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
>>> - Campbell
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> Bf-committers mailing list
>> Bf-committers at blender.org
> - Campbell
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers