Hi, Nice proposal! :)
Le 19/12/2011 11:56, Sergey Sharybin a écrit : > 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. I’d also tend to at least have a star for each new comment line – it is a bit tedious to edit, but really ease reading, imho, even with syntax highlight. ;) >> 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 :) Well, on this point I don’t have a strong opinion, though I tend to use the "no space" style… >> 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. Pep8 or not, I really prefer the "a<space>=<space>b" style! But that’s not a really critical point. :) >> 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 >> _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
