[m-users.] Coding style

[Richard O'Keefe]

Using . to indicate a space, I use
if.(xxxxxxxxxxxxxx
.&&.yyyyyy
.&&.zzzzase
).{
which I find makes the structure much easier to see.  The rule is that when
broken across lines, && and
|| go at the beginning, lining all the conjuncts or disjuncts up neatly.
In Prolog, Mercury, and Erlang I make it a rule to put semicolons in
if-like or case-like constructs
as the first token of a line because they're far too easy to overlook at
the end.



On Fri, 23 Jan 2026 at 17:54, Paul Bone <paul at bone.id.au> wrote:

> I realise that my eyesight is a bit of a "special case" so I don't
> represent the majority, but also it can be important to speak up.  I know
> many of you know I can see appropriately 10-20% of what most people can see
> (the number is vague because it depends on the situation)
>
> I'm using a 24" screen on my desk, I can put 2 80 column terminals
> side-by-side and I have a little space left over.  I still find 80 columns
> very comfortable, it doesn't feel restrictive if my lines are too long
> sometimes punctuating them with newlines helps readability because the
> structure becomes more apparent due to indentation.
>
> Mozilla's (where I work) coding standard and auto-formatter use 80
> columns.  I was initially unsure of using an autoformatter (and two spaces
> per tab!) but I've been converted about the autoformatter,  2, 3 or 4
> spaces per tab would all be fine.  2 is kinda nice because then something
> like:
>
> if (long_expression &&
>     gets_double_indent) {
>   single_indent_here();
> }
>
> the condition is indented more deeply than the body, but yet it's only 2
> spaces so you don't run out of horizontal space quickly.  The brace could
> be on the new line, I don't mind.
>
> Which makes me think maybe 80 is less restrictive if you also have smaller
> indentation.
>
> On Fri, 23 Jan 2026, at 3:33 PM, Richard O'Keefe wrote:
> > There are good reasons that newspapers use narrow columns and many
> > journals and conferences use two-column format.
> > My Prolog style switched from 8-column indents to 4-column indents
> > years ago to improve readability.
> > I had a former colleague who was fond on full-monitor-width lines and
> > it was physically painful to read his code.
> > There are studies that say things like "reading text on a computer
> > screen is really exhausting" and "reading on a computer screen is
> > about 30% slower than reading printed text" and "longer lines require
> > increased line spacing" for readability" and "studies have recommended
> > that line length should not exceed about 70 characters per line" for
> > readability "both very short and very long lines slow down reading by
> > interrupting the normal pattern of eye movement."
> >
> > With source code, we tend to do more *searching* than *reading
> > through*.  Long dense lines make searching hard.  I am not referring
> > to the kind of thing your text editor/IDE has for a 'search' command
> > unless you have a truly exceptional text editor that can express
> > structural patterns.  My former colleague believed he *needed*
> > extra-long lines because his variable names averaged about 20
> > characters long and his method names averaged about 30 characters
> > long.  He was half right: once you found a chunk of code you were in
> > little doubt about what it meant.  He was half wrong: it was the very
> > devil trying to distinguish between
> > current_input_stream_number_of_lines_read and
> > current_input_stream_number_of_lines_readable.
> >
> > With source code, searching often involves more than one document.
> > When using R or Octave, I use the integrated help a *lot* so it
> > matters that the help and the file don't interfere with each other.
> > I'm often trying to look at a use of some name and the definition of
> > that name at the same time, and they are often in different files.  I
> > suggest that the best use of wide screens is to have several documents
> > side by side.
> >
> > I must also point out that my most recent laptop has a 14-inch display
> > and that due to my spectacle prescription I'm a lot more comfortable
> > reading larger fonts.  The line width usable by someone with a 32-inch
> > monitor on their desk who is comfortable with 10 point type is a LOT
> > bigger than the line width usable by someone with a 14-inch laptop who
> > is more comfortable with 14-point type (who also has to keep a margin
> > clear for the Dock or its equivalent).  (Yes, I could buy a 32-inch
> > HDMI monitor that would plug into my laptop.  As it happens, I did.
> > But the point of a laptop is to be able to use it in places like the
> > local Chinese Garden, for which I have a season ticket, where I can't
> > plug the outboard monitor in.)
> >
> > So when choosing your line length, please consider
> >  - people with 14-inch laptop screens
> >  - who need a larger font than you do
> >  - who are NOT familiar with your code and need to do a lot of searching
> >  - and really need to have multiple documents (use + definition, use
> > or definition + documentation)
> >    open at the same time.
> >
> >
> > On Thu, 22 Jan 2026 at 00:49, Julien Fischer <jfischer at opturion.com>
> wrote:
> >>
> >> Hi Ralph,
> >>
> >> On Wed, 21 Jan 2026 at 17:30, Ralph Becket <ralphbecket at outlook.com>
> wrote:
> >> >
> >> > Happy New Year!
> >>
> >> Happy new year to you too!
> >>
> >> > About twenty years back, when I left Mercury to start in mainstream
> commercial programming, monitors were a lot narrower.  There was a strong
> feeling then that 80 columns was the Right and Proper Line Length.
> Nowadays, of course, monitors are much more generous.  While I reject
> uncontrolled line lengths, 80 columns seems painfully tight.  (I think the
> Linux developers moved away from this some years
> >> ago).  That said, when (back) in Rome, do as the Romans do.  So:
> >> what's the modern community position on this?
> >>
> >> In the Mercury project itself, it's still 80 columns (actually 79, due
> >> to diff adding an extra character).
> >>
> >> Outside of Mercury, I tend not to go beyond that too much (unless
> >> horribly verbose things like Java
> >> are involved).
> >>
> >> Julien.
> >> _______________________________________________
> >> users mailing list
> >> users at lists.mercurylang.org
> >> https://lists.mercurylang.org/listinfo/users
> > _______________________________________________
> > users mailing list
> > users at lists.mercurylang.org
> > https://lists.mercurylang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20260124/d83119eb/attachment-0001.html>