[Bf-committers] line length / code style.

[Bastien Montagne]

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<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.
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<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
>>