On 11/11/2020 17:27, Gedare Bloom wrote:
On Tue, Nov 10, 2020 at 12:25 AM Sebastian Huber
<sebastian.hu...@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.
I never noticed code sections which use this two level indentation for a
line continuation. Do you know an example off hand?
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
