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
