80 or 79 characters limit?
Gedare Bloom
gedare at rtems.org
Thu Nov 5 20:28:21 UTC 2020
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.
>
> Not accepting unicode should be checked for patches and should be in
> Coding Conventions.
>
> I think you made a couple of bad mapping choices.
>
> - "(r)" for the registered symbol (circle R)
> - "u" for the micro Greek letter in usec and us (which is strange for usec)
>
> 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.
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
>
> --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
More information about the devel
mailing list