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 <[email protected]> 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 <[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 > > > > -- > - 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
