On 07/01/2025 14:19, nick wrote:
> I am also a firm believer in lines of 80 columns. This occasionally
> brings me into conflict with younger colleagues who see this as
> arbitrary and generally are using IDEs in which any width can be
> displayed. Usually they have multiple, huge monitors and smallish
> letters, so they think "why not!".
>
> I haven't heard it articulated before why 80 (or indeed 72) columns is a
> good thing. I guess in my case it's because I usually use a laptop
> screen with largeish letters, but also just for the sake of
> standardization. My feeling is there must be a limit, so the limit
> should be defined. The value is unimportant, if we could all agree on
> 132 characters (does anyone remember dot matrix printers that could
> print 80 columns normal size, 132 condensed?) , then that would be okay
> with me, but the consensus does seem to be 80.
As you state, I believe the exact amount of columns in a line is less
important than simply having some sensible limit.
A 100, 120 or perhaps longer limit might make more or less sense
depending on the language. Some languages tend to waste a fair bit of
horizontal space on indentation or other syntax.
The main objective is avoiding too much complexity on a single line.
I tend to hover around 100 FWIW.
Another reason I prefer not to write long lines is that I usually have 2
or more windows open, stacked horizontally. If lines span an entire
monitor they wrap around in an ugly way (or just get cut off, depending
on the editor).
> I have an interesting system for dealing with long lines in source code,
> that also sometimes brings me into conflict with colleagues. They often
> want to start continuation lines with extra indents and often it is
> context dependent, e.g. they do:
> void this_is_a_long_function(int a, int b,
> int c, int d);
> where "int a" and "int c" are aligned by putting loads of spaces. I do
> not do it that way. What I do is, if something in parentheses (or braces
> or whatever) must be broken then each item inside has to be on its own line:
> void this_is_a_long_function(
> int a,
> int b,
> int c,
> int d
> );
> With this scheme the item on each line can be up to the line width, for
> example an expression like (a+b)/(c+d) can have (a+b)/ on the first line
> and (c+d) on the second line, and the expression on each line can be
> arbitrarily complicated but must be < 80 characters including its indent
> and must be a syntactic expression, i.e. parentheses must be balanced.
> Similarly for declarations, etc.
>
> Also, once it is determined to break an expression into multiple lines,
> every outer expression or statement containing that expression must also
> be broken. But subexpressions of those need not be.
I tend to prefer the first signature since the amount of rows is limited
too. Though perhaps I'd write it something like this instead:
void this_is_a_long_function(
int a, int b, int c, int d
);
It might be worth using an formatter like clang-format, which can
unambiguously enforce a single style.
> An annoying dilemma arises for me when things are not parenthesized. This:
> long_variable_name =
> complicated_expression;
> Or this:
> long_variable_name =
> complicated_expression;
> Or even this, recommended for Python where linebreaks are significant:
> long_variable_name = (
> complicated_expression
> );
>
> In such cases I will go with whatever I feel like. But someday I would
> like to create an editor that does such breaking and un-breaking for me
> automatically. So I'll have to decide the rule unambiguously. Hmm.
I usually use a backslash (\) for breaking up long lines in Python.
long_variable_name = \
complicated_expression
> Kind regards,
> Nick
>> On 7 Jan 2025 at 11:00 pm, dng-request <dng-request@???
>> <mailto:dng-request@lists.dyne.org>> wrote:
>>
>> Send Dng mailing list submissions to
>> dng@??? <lists.dyne.org>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng <https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng>
>> or, via email, send a message with subject or body 'help' to
>> dng-request@??? <lists.dyne.org>
>>
>> You can reach the person managing the list at
>> dng-owner@??? <lists.dyne.org>
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Dng digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: HTML/SVG/PostScript [was: ...more about the Xaw widget
>> set] (Didier Kryn)
>> 2. Re: HTML/SVG/PostScript [was: ...more about the Xaw widget
>> set] (Dan Purgert)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 7 Jan 2025 12:09:00 +0100
>> From: Didier Kryn <kryn@???>
>> To: dng@??? <lists.dyne.org>
>> Subject: Re: [DNG] HTML/SVG/PostScript [was: ...more about the Xaw
>> widget set]
>> Message-ID: <ffbc8fa0-1734-4acd-8c18-c305c1bc1aa5@???>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Le 07/01/2025 ? 00:06, o1bigtenor via Dng a ?crit?:
>> > Trying to learn something from reading threads - - - -
>> >
>> > Why would the lines be too long - - - - more than 80 characters isn't
>> > tolerated - - - or ???????????
>>
>> ??? I try to keep everything within 80 chars wide, possibly overriding
>> a little bit for things like HTML, never for programming languages.
>> Longer lines tend to be hard to read. Did you notice that in books and
>> newspapers, lines are kept relatively short. When a line is too long it
>> becomes hazardous for the eye to go to the next, at least for me. I
>> suppose its the reason why text formatting tools support multicolumn.
>>
>> ??? If you open any free software source file, you will notice that it
>> also fits in 80 columns. Always. So it isn't just me.
>>
>> -- ??? Didier
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 7 Jan 2025 06:54:06 -0500
>> From: Dan Purgert <dan@???>
>> To: dng@??? <lists.dyne.org>
>> Subject: Re: [DNG] HTML/SVG/PostScript [was: ...more about the Xaw
>> widget set]
>> Message-ID: <Z30V3kRlX-nFsb81@??? <framework.djph.net>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> On Jan 07, 2025, Didier Kryn wrote:
>> > Le 07/01/2025 ? 00:06, o1bigtenor via Dng a ?crit?:
>> > > Trying to learn something from reading threads - - - -
>> > >
>> > > Why would the lines be too long - - - - more than 80 characters isn't
>> > > tolerated - - - or ???????????
>> >
>> > ??? I try to keep everything within 80 chars wide, possibly overriding a
>> > little bit for things like HTML, never for programming languages. Longer
>> > lines tend to be hard to read. Did you notice that in books and
>> > newspapers, lines are kept relatively short. When a line is too long
>> > it becomes hazardous for the eye to go to the next, at least for me. I
>> > suppose its the reason why text formatting tools support multicolumn.
>> >
>> > ??? If you open any free software source file, you will notice that it
>> > also fits in 80 columns. Always. So it isn't just me.
>>
>> I think I've come across some that run wide, though that might just be
>> due to bad naming conventions "required" by the language (things like
>> org.sun.java.xyzzy.some.other.widget <org.sun.java.xyzzy.some.other.widget>).
>>
>> But otherwise I wholeheartedly agree that line-breaks at ~80 columns are
>> quite reasonable for the sake of readability. I have my editor
>> hard-break at 72 (or the nearest whitespace before 72, in the event of a
>> long word), as that seems to work best with mailing lists and other
>> places where formatting will be prefixed.
>>
>> It does admittedly take some getting used to if you're more accustomed
>> to flowed text that defaults to take the entire width of your screen --
>> I remember being confused at the "poor" formatting of RFCs the first
>> time I was introduced to them back in highschool ...
>>
>> --
>> |_|O|_|
>> |_|_|O| Github: https://github.com/dpurgert <https://github.com/dpurgert>
>> |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 833 bytes
>> Desc: not available
>> URL: < <https://mailinglists.dyne.org/cgi-bin/mailman/private/dng/attachments/20250107/6fc84a0d/attachment.sig>>https://mailinglists.dyne.org/cgi-bin/mailman/private/dng/attachments/20250107/6fc84a0d/attachment.sig <https://mailinglists.dyne.org/cgi-bin/mailman/private/dng/attachments/20250107/6fc84a0d/attachment.sig>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Dng mailing list
>> Dng@??? <lists.dyne.org>
>> Manage your subscription: https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng <https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng>
>> Archive: https://lists.dyne.org/lurker/list/dng.en.html <https://lists.dyne.org/lurker/list/dng.en.html>
>>
>>
>> ------------------------------
>>
>> End of Dng Digest, Vol 124, Issue 10
>> ************************************
>>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> Manage your subscription: https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> Archive: https://lists.dyne.org/lurker/list/dng.en.html
::
Re: [DNG] Line length
