[Bf-committers] line length / code style.

Sergey Sharybin sergey.vfx at gmail.com
Mon Dec 19 14:34:03 CET 2011

> 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

More information about the Bf-committers mailing list