[Bf-committers] line length / code style.

Nicholas Bishop nicholasbishop at gmail.com
Mon Dec 19 14:59:26 CET 2011


I'm basically fine with this proposal. Don't know if it's worth
enforcing completely, but if that's the way we want to go I wouldn't
object to a commit hook enforcing it.

On breaking long lines, this is probably the only thing I care
strongly about. I find it very helpful to split my editor into
multiple views to show source files displayed next to each other, and
long lines make this harder to do. I prefer we keep to 80-char limit;
if others see this as not practical, perhaps we could say hard-limit
is 120, but 80 is preferred where reasonable?

Other things:
+1 to no space between keyword and open paren
-1 to star at the beginning of each comment line

Small notes on indentation:
1) Some switches in Blender have the cases indented (so the case
bodies are double indented from the switch() block), others have the
cases lined up with the switch(), might want to bless one of these
styles (my vote would be to the second style.)
2) If we really are going to start changing all the code to conform to
a new style, might be worth switching C code to all spaces rather than
tabs + spaces for aligning wrapped lines. Then we avoid the whole
tab-width question. If not, at least the recommended tab width should
be specified in the coding standard.

Thanks,
-Nicholas

On Mon, Dec 19, 2011 at 8:34 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>>
>> I prefer no space, don't see why there should be a difference because
>> one is a keyword and the other a function call, it's still just an
>> arbitrary choice. But I can live with the proposed coding style up to
>> now.
>>
>
> It's just more matter of readability which is a bit subjective and
> unfortunately it can't be solved in a way everybody is happy of it. I might
> only collect opinions of developers and prepare proposal based on it.
> Unless Ton tell "if must be no space here" i can't force the whole comunity
> to switch to this style.
>
> Another inconsistency is in variable/function/struct/macro names. The
>> rules there tend to be variables lowercase (often without _ separator
>> but not always), functions also lower case (with _ separator) except
>> for the module prefix, structs camel case starting with capital
>> letter, and macros all uppercase (with _).
>>
>
> Yes, and it's not only remained inconsistency.Will continue collecting them
> and documenting next two-three days (depening on how i'll be busy with
> other tasks) .
>
> I'd love to see existing code changed to enforce all this, and
>> personally wouldn't mind it adding an extra step to svn blame, but not
>> everyone might agree with that.
>>
> Yes, switchig existing code code to new style will reduce confusages of
> code style. But it might be a bit pain for branches and i think it might
> worth of separating such kind of refactor, so there wouldn't be a task for
> one developers only.
>
> Another question i've got is related on code style in intern/. My opinion
> that we shouldn't be strict about libs from there, but be more about
> "following this code  style in intern/ is really welcome". Maybe somebody
> have got another opinion here?
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list