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.



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.



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.



Kind regards,

Nick








>
> On 7 Jan 2025 at 11:00 pm, dng-request <dng-request@???> wrote:
>
>
> Send Dng mailing list submissions to
> dng@???
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> or, via email, send a message with subject or body 'help' to
> dng-request@???
>
> You can reach the person managing the list at
> dng-owner@???
>
> 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@???
> 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@???
> Subject: Re: [DNG] HTML/SVG/PostScript [was: ...more about the Xaw
> widget set]
> Message-ID: <Z30V3kRlX-nFsb81@???>
> 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).
>
> 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
> |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>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> 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
>
>
> ------------------------------
>
> End of Dng Digest, Vol 124, Issue 10
> ************************************
>