80 or 79 characters limit?
Joel Sherrill
joel at rtems.org
Thu Nov 5 20:51:40 UTC 2020
On Thu, Nov 5, 2020 at 2:42 PM Christian Mauderer <oss at c-mauderer.de> wrote:
> On 05/11/2020 21:28, Gedare Bloom wrote:
> > On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill <joel at rtems.org> wrote:
> >>
> >> I tried at one point to figure out how to script the changes when I ran
> into them.
> >> But it was easier to fix them by hand. If you have a simple script, it
> would be good
> >> to have a home for it. We could grow it then.
>
> Sorry, I didn't use a script either. I just wanted to try a tool on a
> larger code base and blindly removed everything that has been a problem
> for it.
>
Well this is a challenge for another day. We can always use file and if
gives the wrong answer, then we know something is broken in the file.
>
> >>
> >> Not accepting unicode should be checked for patches and should be in
> >> Coding Conventions.
> >>
> >> I think you made a couple of bad mapping choices.
>
> See above: The target was not to have a good choice but just to get rid
> of them. Never intended to create a real patch from it. But like I said:
> I'll polish it a bit and send patches.
>
Thanks.
>
> >>
> >> - "(r)" for the registered symbol (circle R)
> >> - "u" for the micro Greek letter in usec and us (which is strange for
> usec)
>
> For me "s" is a quite common short for seconds. And u is quite common
> for replacing a micro if there is no special micro character. Most
> likely in English there is a higher chance to mis-read it as an "us"
> like the one in "tell us something" and therefore the short form is
> considered strange ;-)
>
I have seen people use msec or ms for microsecond and that is wrong.
I tend to like to see millisecond and microsecond spelled out unless
there is a really good reason not to. Usually there is plenty of space to
hedge on the side of perfect clarity.
>
> >>
> >> Some I have no idea about.
> >>
> >> + aes.c - absolutely no idea
> >> + rtl22xx/console/uart.c - maybe an x
> >> + powerpc/include/mpc83xx/mpc83xx.h - maybe an x
> >>
> >> I think a patch series doing copyright symbols, (r), and u for micro
> >> as individual changes would eliminate a lot and not be controversial.
> >> That should leave the remaining for a second pass.
> >>
> >> One patch per character change is safer to review.
> > "per kind of character"
> >
> > feel free to send all the (C) together, etc.
>
> OK.
>
> >
> > I think the AES one is pTq, math notation for a vector product using
> transpose.
> >
> > I used https://www.branah.com/unicode-converter and put the UTF-8 we
> > have in our repo in the box, and that gives some idea what it should
> > be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see
> > what pops out on top
>
> That's a nice tool. Thanks for the hint.
>
> Best regards
>
> Christian
>
> >
> >>
> >> --joel
> >>
> >>
> >> On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer <oss at c-mauderer.de>
> wrote:
> >>>
> >>> Hello Joel,
> >>>
> >>> On 05/11/2020 20:15, Joel Sherrill wrote:
> >>>>
> >>>>
> >>>> On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer <oss at c-mauderer.de
> >>>> <mailto:oss at c-mauderer.de>> wrote:
> >>>>
> >>>> Hello Joel and Sebastian,
> >>>>
> >>>> On 05/11/2020 16:44, Joel Sherrill wrote:
> >>>> >
> >>>> >
> >>>> > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
> >>>> > <sebastian.huber at embedded-brains.de
> >>>> <mailto:sebastian.huber at embedded-brains.de>
> >>>> > <mailto:sebastian.huber at embedded-brains.de
> >>>> <mailto:sebastian.huber at embedded-brains.de>>> wrote:
> >>>> >
> >>>> > Hello,
> >>>> >
> >>>> > I review currently the Coding Conventions. Should the 80
> >>>> characters
> >>>> > limit be really a 79 characters limit with the \n as the
> >>>> invisible 80th
> >>>> > character?
> >>>> >
> >>>> >
> >>>> > Yes.
> >>>> >
> >>>> > As old as this makes me feel, I remember printers which did an
> >>>> automatic
> >>>> > linefeed and then the newline one if you hit column 80. So it
> >>>> really is
> >>>> > 79 unfortunately.
> >>>>
> >>>> I don't think printers with an automatic linefeed are a common
> use case
> >>>> for reading the RTEMS source code nowadays. So that maybe isn't
> the best
> >>>> reason for using 79 characters.
> >>>>
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>> I would suggest to use the same convention that most coding
> styles use
> >>>> which seems to be 80 characters:
> >>>>
> >>>>
> https://en.wikipedia.org/wiki/Characters_per_line#In_programming
> >>>>
> >>>> At least if there are no more recent examples for tools or
> editors where
> >>>> 79 is a benefit. 80 seems just feels a bit more natural.
> >>>>
> >>>>
> >>>> By the way: If we count '\n': Should we count a tab '\t' as a
> single
> >>>> character, as 2, as 4 or as 8 ones?
> >>>>
> >>>>
> >>>> We shouldn't have tabs in code we own.
> >>>
> >>> Good point.
> >>>
> >>>>
> >>>> What about the few Unicode
> >>>> characters that slipped in over the years?
> >>>>
> >>>>
> >>>> We also shouldn't have unicode characters randomly floating around.
> They
> >>>> tend to pop up in my experience when people copy from word processors
> >>>> and get fancy quotes. Those cases should be eliminated
> >>>
> >>> Last time I stumbled across a tool that didn't like unicode characters
> I
> >>> found about 75 lines in RTEMS with unicode characters. I have been to
> >>> lazy to fix them back then. Mostly because some of them would have
> >>> needed some thought about what there should have been (I assume it has
> >>> been a microsecond in some cases, but still not sure). Attached you can
> >>> find a patch that should replaces most of them without much thought
> >>> about the content. If you think it's useful, I can polish it up a bit.
> >>>
> >>> Best regards
> >>>
> >>> Christian
> >>>
> >>>>
> >>>>
> >>>> Best regards
> >>>>
> >>>> Christian
> >>>>
> >>>> >
> >>>> >
> >>>> > --
> >>>> > embedded brains GmbH
> >>>> > Sebastian HUBER
> >>>> > Dornierstr. 4
> >>>> > 82178 Puchheim
> >>>> > Germany
> >>>> > email: sebastian.huber at embedded-brains.de
> >>>> <mailto:sebastian.huber at embedded-brains.de>
> >>>> > <mailto:sebastian.huber at embedded-brains.de
> >>>> <mailto: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 <mailto:devel at rtems.org>
> >>>> <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> >>>> > http://lists.rtems.org/mailman/listinfo/devel
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > devel mailing list
> >>>> > devel at rtems.org <mailto:devel at rtems.org>
> >>>> > http://lists.rtems.org/mailman/listinfo/devel
> >>>> >
> >>>>
> >>
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201105/46277e90/attachment-0001.html>
More information about the devel
mailing list