[U-Boot] White space cleanup

[U-Boot] White space cleanup

[Wolfgang Denk]

Hi Tom,

the recent issue with CR / CRLF sequences in a shell script tiggered
me to hae a closer look at such issues in other areas, and I
dicovered a lot of formal coding style issues like C++ comments,
trailing white space, leading white space (indentation not by TABs),
excessive blank lines, trailing blank lines which I would like to
clean up.

However, this affects more than 500 files, so it might cause a large
number of mege conflicts with other changes.

When would be a good point of time in the release cycle to submit
such a patch series?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"One day," said a dull voice from down below, "I'm going to  be  back
in  form again and you're going to be very sorry you said that. For a
very long time. I might even go so far as to make even more Time just
for you to be sorry in."              - Terry Pratchett, _Small Gods_

[U-Boot] White space cleanup

[Tom Rini]

On Fri, Nov 08, 2019 at 09:39:44AM +0100, Wolfgang Denk wrote:

> Hi Tom,
> 
> the recent issue with CR / CRLF sequences in a shell script tiggered
> me to hae a closer look at such issues in other areas, and I
> dicovered a lot of formal coding style issues like C++ comments,
> trailing white space, leading white space (indentation not by TABs),
> excessive blank lines, trailing blank lines which I would like to
> clean up.
> 
> However, this affects more than 500 files, so it might cause a large
> number of mege conflicts with other changes.
> 
> When would be a good point of time in the release cycle to submit
> such a patch series?

Lets see.  For '//' style comments, while I personally can't bring
myself to use them, most of what we have today is generated files or
external project files.  Given that the Linux kernel no longer complains
about it (and per the last thread about them, they're C99 comments, and
that's 20 years ago now), it's probably best to just say they're
discouraged but also that:
	writel(1, DDRPHY_CONFIG_BASE + 0x134); // DATA0_REG_PHY_USE_RANK0_DELAYS
is at least as readable if not more so than:
	writel(1, DDRPHY_CONFIG_BASE + 0x134); /* DATA0_REG_PHY_USE_RANK0_DELAYS */

which goes past 80 chars wide, rather than sticking to 80.

For the whitespace stuff, whenever is fine, being careful of stuff we
sync from elsewhere rather than is our own.  Whitespace changes there
make future resync harder.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191108/bbad753e/attachment.sig>

[U-Boot] White space cleanup

[Wolfgang Denk]

Dear Tom,

In message <20191108151810.GY19317@bill-the-cat> you wrote:
> 
> > When would be a good point of time in the release cycle to submit
> > such a patch series?
>
> Lets see.  For '//' style comments, while I personally can't bring
> myself to use them, most of what we have today is generated files or
> external project files.  Given that the Linux kernel no longer complains
> about it (and per the last thread about them, they're C99 comments, and
> that's 20 years ago now), it's probably best to just say they're
> discouraged but also that:
> 	writel(1, DDRPHY_CONFIG_BASE + 0x134); // DATA0_REG_PHY_USE_RANK0_DELAYS
> is at least as readable if not more so than:
> 	writel(1, DDRPHY_CONFIG_BASE + 0x134); /* DATA0_REG_PHY_USE_RANK0_DELAYS */
>
> which goes past 80 chars wide, rather than sticking to 80.

Agreed.  I guess age brings that I also feel less fanatic here ;-)

> For the whitespace stuff, whenever is fine, being careful of stuff we
> sync from elsewhere rather than is our own.  Whitespace changes there
> make future resync harder.  Thanks!

Sure.  But you did not answer my key question:

When would be a good point of time in the release cycle to submit
such a patch series?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The price of curiosity is a terminal experience.
                         - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot] White space cleanup

[Tom Rini]

On Fri, Nov 08, 2019 at 05:55:03PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20191108151810.GY19317@bill-the-cat> you wrote:
> > 
> > > When would be a good point of time in the release cycle to submit
> > > such a patch series?
> >
> > Lets see.  For '//' style comments, while I personally can't bring
> > myself to use them, most of what we have today is generated files or
> > external project files.  Given that the Linux kernel no longer complains
> > about it (and per the last thread about them, they're C99 comments, and
> > that's 20 years ago now), it's probably best to just say they're
> > discouraged but also that:
> > 	writel(1, DDRPHY_CONFIG_BASE + 0x134); // DATA0_REG_PHY_USE_RANK0_DELAYS
> > is at least as readable if not more so than:
> > 	writel(1, DDRPHY_CONFIG_BASE + 0x134); /* DATA0_REG_PHY_USE_RANK0_DELAYS */
> >
> > which goes past 80 chars wide, rather than sticking to 80.
> 
> Agreed.  I guess age brings that I also feel less fanatic here ;-)
> 
> > For the whitespace stuff, whenever is fine, being careful of stuff we
> > sync from elsewhere rather than is our own.  Whitespace changes there
> > make future resync harder.  Thanks!
> 
> Sure.  But you did not answer my key question:
> 
> When would be a good point of time in the release cycle to submit
> such a patch series?

Ah, I wasn't clear enough.  Whenever you post them, I'll integrate them.
We shouldn't be getting new problems here as I think they're mostly
historical.  I do try and look at everything checkpatch tells me and
that in turn should keep new whitespace problems from coming in.
Assuming you do it with a git grep | xargs sed, dropping that below the
'---' in the patch will make any re-fixing up easier too.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191108/218ed49b/attachment.sig>