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 <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
