[Bf-committers] line length / code style.

[Campbell Barton]

On Wed, Dec 21, 2011 at 5:27 AM, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
>
>> c'mon! - http://www.graphicall.org/ftp/ideasman42/long_lines.png
>
> That's not a good example.
>
> Some of these long lines are great to be in 1 line; because they're
> just not meant to be read as code really (it's data, a long string, or
> just lot of crap).
>
> The "rule" for line length is not about numbers (80 or 120) but about
> producing readable code, emphasizing structure and functionality and
> to assist debugging. A developer can use own insights and style to
> follow this in sane ways.
>
> For that reason, the line length rule is not a rule (like always
> capitalize #defines) but an important guideline; follow it to produce
> readable code, based on your insights for it.
>
> Splitting the code guide in "Rules" and "Guides" would be also helpful
> to prevent lengthy discussions.
>
> You know; "strict in what we agree on, freedom in our doubts, love for
> all!" :)
>
> -Ton-

Yep,
I'm aware of this should be some strict rule we apply blindly.

My point is that since some lines are so incredible long they should
be split, we should probably set some line length to split them at
rather then each dev having their own.


To referencing that image again:
http://www.graphicall.org/ftp/ideasman42/long_lines.png


Example of data (shouldn't be changed --- or only changed by the
maintainer if they really want to)
- unit.c:274

Example of code that should be split (unless maintainers really _don't_ want to)
- editmesh.c:925
- sculpt.c:595
- transform_snap.c:1625

...that leaves function calls and definitions:
- makesrna.c: all long lines
- interface.c: all long lines

IMHO - these should be up to the maintainer(s) weather to split or not.

- Campbell