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