[Bf-committers] line length / code style.

[Sergey Sharybin]

Hi,

On Mon, Dec 19, 2011 at 4:24 PM, Joshua Leung <aligorith at gmail.com> 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 <sergey.vfx at gmail.com>
> 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
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin