[Bf-committers] line length / code style.

[Campbell Barton]

On Tue, Dec 20, 2011 at 12:59 AM, Nicholas Bishop
<nicholasbishop at gmail.com> wrote:
> 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?

I tried setting the margin to 80 and conforming to it where possible,
but think we cant really do this in many files, so 120, but 80 if
authors wish - is fine by me.

> Other things:
> +1 to no space between keyword and open paren

Not too fussed either way, tho have been writing spaces recently, if
others prefer no space, I'm not fussed.

> -1 to star at the beginning of each comment line

Still prefer star.

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

I'm not really fussed either way, +1 for picking one.

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

-1 for switching tabs to spaces, mainly because Its a fairly big
change, thought we already had a tab-width of 4 defined somewhere.

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell