[Bf-committers] line length / code style.
ton at blender.org
Mon Dec 19 17:01:27 CET 2011
Your proposal has very subjective rules, and renders all old code to
The idea to have code over many lines with only few characters (to fit
unix terminals) was already outdated when I started C in 1991 (on SGI,
I learned C with SGI code too, using their code as style guide. (Never
seen that guide, but the SGI code was very consistant and well
Let me try to make an alternative guide, a bit more liberal at least.
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 19 Dec, 2011, at 14:34, Sergey Sharybin 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
> 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
> 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
>> everyone might agree with that.
> Yes, switchig existing code code to new style will reduce confusages
> code style. But it might be a bit pain for branches and i think it
> 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
> that we shouldn't be strict about libs from there, but be more about
> "following this code style in intern/ is really welcome". Maybe
> have got another opinion here?
> With best regards, Sergey Sharybin
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers