Breaking Long Lines

[Gedare Bloom]

On Tue, Nov 10, 2020 at 12:25 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> On 10/11/2020 06:33, Chris Johns wrote:
>
> >> My question is if we really should indent by two levels for the continuation of
> >> long lines.
> > And my answer was it depends on what is being indented and why. The block
> > nesting level can also effect what works.
> I would like to focus on this particular case.
> >
> >> variable = ...
> >>
> >> <SP><SP><SP><SP>foo bar continuation ...
> >>
> >> vs.
> >>
> >> variable = ...
> >>
> >> <SP><SP>foo bar continuation ...
> > I think most editors will assume this level of indenting rather than the double
> > indent level.
>
> Yes, also I doubt such a special case double indentation can be
> configured in automatic code formatting tools.
>
> So, can I commit this change?
>
> https://lists.rtems.org/pipermail/devel/2020-November/063094.html
>

I think this rule has been long standing. I wonder how much code is affected.

Anyway, whether it is one indent level or two is not a great concern
to me. I believe the use of two has been to make broken lines more
obvious vs nesting. But when we have explicit curly brackets {} and
the operator trails at the end of the line, I think one indent level
is OK. As with many style things, it seems not a big deal either way.
If it makes the code easier to maintain with style tools, then I say
go for it.

> --
> embedded brains GmbH
> Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> Phone: +49-89-18 94 741 - 16
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> embedded brains GmbH
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel