Hi, On Mon, Dec 19, 2011 at 4:24 PM, Joshua Leung <[email protected]> wrote:
> Hi, > > Over the weekend, I've posted my thoughts on a few of these issues [1]. > Will check that soon (when all curent ssvn merge stuff is over) > > Regarding your proposal, I agree with most of the issues brought up. > HOWEVER, > 1) I prefer the version of comments with a starting indicator on each > line + closing on a separate line. > Yes, when comment is few lnes only, it's ok. But when documentation is more detailed (multires stuff, math_geom, ...) it might be annoying to deal with an indicator on each line. > > 2) Spacing *should* be used between a builtin keyword and an opening > brace. Keywords != function calls. > I wouldn't be so categoric here and say "it might be used". Reading code from BKE/BLI i didn't see way which is more preferable atm. Reason of current state of this tip is simple: in most of modules i was working, spaces weren't used much after keyword. It's not so big deal to replace that tip to "space shoudl be used", but imo it'll worth asking other devs and if most of devs are fine with such change -- it'll be changed :) > > 3) Assignment operators: my opinion of this has varied in the past, > though I'm now tending towards the "a = b" (NOT "a= b") camp. While > easier to type the second version, it doesn't hold up that well for > compound assignment (+=, -=, and friends). However, it should also be > noted that Python's PEP8 (which we use for our scripts) explicitly > states for this case that there should be spaces. > PEP8 isn't good reference here: it tells TABs mustn't be used ;) Again, it was added based on reading code from BLI/BKE/moules i was working before. It is possible to change to "a<space>=<space>b" style but i want most of active devs agree on this. > > 4) Trailing whitespace - make sure you get your definition of > "trailing" correct. If it's the defined by the lazy implementation of > most text editors, then I'd have to disagree with enforcing it ;) > It means spaces at the end of line with operator be better eb stripped: "int foo, bar;" instad of "int foo, bar;<tab><tab>". It's a bit picky tip and it tells not "MUSTN"T BE" it tells "better be avoided" > > [1] > http://aligorith.blogspot.com/2011/12/avoiding-degenerative-coding-practices.html > > On Mon, Dec 19, 2011 at 10:54 PM, Sergey Sharybin <[email protected]> > wrote: > > Hi, > > > > I've prepared first draft of code style guideline [1]. Of course it > needed > > to be finished and probably more adopted for existing code style in > > Blender, i'll continue working on this. Want to have feedback from active > > debelopers about things from rules needed to be discussed section. > > > > Also feel free to propse changes to existing tips or propose new tips. > > > > [1] http://wiki.blender.org/index.php/User:Nazg-gul/CodeStyle > > > > -- > > With best regards, Sergey Sharybin > > _______________________________________________ > > 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 > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
