80 or 79 characters limit?

Christian Mauderer oss at c-mauderer.de
Thu Nov 5 20:42:50 UTC 2020 

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.

>>
>> 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.

>>
>> - "(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 ;-)

>>
>> 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
>

More information about the devel mailing list