[Bf-committers] line length / code style.

[Ton Roosendaal]

Hi Sergey,

Your proposal has very subjective rules, and renders all old code to  
be 'bad'.

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,  
OK :)...

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

Let me try to make an alternative guide, a bit more liberal at least.

-Ton-

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