Re: [m-users.] Coding style
"Richard O'Keefe" <[email protected]> Sat, 24 Jan 2026 00:46:20 +1300
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <CABcYAdL7YzmoW5SyULMQQ1gtO-MDwwrewf-hM-bxALvZiiYOtg@mail.gmail.com> |
--===============5180192113179540735==
Content-Type: multipart/alternative; boundary="000000000000762fce06490cb52f"
--000000000000762fce06490cb52f
Content-Type: text/plain; charset="UTF-8"
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 <[email protected]> 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 <[email protected]>
> wrote:
> >>
> >> Hi Ralph,
> >>
> >> On Wed, 21 Jan 2026 at 17:30, Ralph Becket <[email protected]>
> 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
> >> [email protected]
> >> https://lists.mercurylang.org/listinfo/users
> > _______________________________________________
> > users mailing list
> > [email protected]
> > https://lists.mercurylang.org/listinfo/users
>
--000000000000762fce06490cb52f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default"></div><div d=
ir=3D"ltr"><font face=3D"monospace">Using . to indicate a space, I use</fon=
t><div><font face=3D"monospace">if.(xxxxxxxxxxxxxx</font></div><div><font f=
ace=3D"monospace">.&&.yyyyyy<span class=3D"gmail_default" style=3D"=
"></span></font></div><div><font face=3D"monospace">.&&.zzzz<span c=
lass=3D"gmail_default">ase</span></font></div><div><font face=3D"monospace"=
>).{</font></div><div><font face=3D"monospace">which I find makes the struc=
ture much easier to see.=C2=A0 The rule is that when broken across lines, &=
amp;& and</font></div><div><font face=3D"monospace">|| go at the beginn=
ing, lining all the conjuncts or disjuncts up neatly.</font></div><div><fon=
t face=3D"monospace">I<span class=3D"gmail_default">n Prolog, Mercury, and =
Erlang I make it a rule to put semicolons in if-like or case-like construct=
s</span></font></div><div><div class=3D"gmail_default"><font face=3D"monosp=
ace">as the first token of a line because they're far too easy to overl=
ook at the end.</font></div><font face=3D"monospace"><br></font></div></div=
><font face=3D"monospace"><br><br></font><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr"><font face=3D"monospace">On Fri, 23 Jan 2026=
at 17:54, Paul Bone <<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>> wrote:<br></font></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><font face=3D"monospace">I realise that my eyesigh=
t is a bit of a "special case" so I don't represent the major=
ity, but also it can be important to speak up.=C2=A0 I know many of you kno=
w I can see appropriately 10-20% of what most people can see (the number is=
vague because it depends on the situation)<br>
<br>
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.=C2=A0 I still find 80 co=
lumns very comfortable, it doesn't feel restrictive if my lines are too=
long sometimes punctuating them with newlines helps readability because th=
e structure becomes more apparent due to indentation.<br>
<br>
Mozilla's (where I work) coding standard and auto-formatter use 80 colu=
mns.=C2=A0 I was initially unsure of using an autoformatter (and two spaces=
per tab!) but I've been converted about the autoformatter,=C2=A0 2, 3 =
or 4 spaces per tab would all be fine.=C2=A0 2 is kinda nice because then s=
omething like:<br>
<br>
if (long_expression &&<br>
=C2=A0 =C2=A0 gets_double_indent) {<br>
=C2=A0 single_indent_here();<br>
}<br>
<br>
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.=C2=A0 The br=
ace could be on the new line, I don't mind.<br>
<br>
Which makes me think maybe 80 is less restrictive if you also have smaller =
indentation.<br>
<br>
On Fri, 23 Jan 2026, at 3:33 PM, Richard O'Keefe wrote:<br>
> There are good reasons that newspapers use narrow columns and many<br>
> journals and conferences use two-column format.<br>
> My Prolog style switched from 8-column indents to 4-column indents<br>
> years ago to improve readability.<br>
> I had a former colleague who was fond on full-monitor-width lines and<=
br>
> it was physically painful to read his code.<br>
> There are studies that say things like "reading text on a compute=
r<br>
> screen is really exhausting" and "reading on a computer scre=
en is<br>
> about 30% slower than reading printed text" and "longer line=
s require<br>
> increased line spacing" for readability" and "studies h=
ave recommended<br>
> that line length should not exceed about 70 characters per line" =
for<br>
> readability "both very short and very long lines slow down readin=
g by<br>
> interrupting the normal pattern of eye movement."<br>
><br>
> With source code, we tend to do more *searching* than *reading<br>
> through*.=C2=A0 Long dense lines make searching hard.=C2=A0 I am not r=
eferring<br>
> to the kind of thing your text editor/IDE has for a 'search' c=
ommand<br>
> unless you have a truly exceptional text editor that can express<br>
> structural patterns.=C2=A0 My former colleague believed he *needed*<br=
>
> extra-long lines because his variable names averaged about 20<br>
> characters long and his method names averaged about 30 characters<br>
> long.=C2=A0 He was half right: once you found a chunk of code you were=
in<br>
> little doubt about what it meant.=C2=A0 He was half wrong: it was the =
very<br>
> devil trying to distinguish between<br>
> current_input_stream_number_of_lines_read and<br>
> current_input_stream_number_of_lines_readable.<br>
><br>
> With source code, searching often involves more than one document.<br>
> When using R or Octave, I use the integrated help a *lot* so it<br>
> matters that the help and the file don't interfere with each other=
.<br>
> I'm often trying to look at a use of some name and the definition =
of<br>
> that name at the same time, and they are often in different files.=C2=
=A0 I<br>
> suggest that the best use of wide screens is to have several documents=
<br>
> side by side.<br>
><br>
> I must also point out that my most recent laptop has a 14-inch display=
<br>
> and that due to my spectacle prescription I'm a lot more comfortab=
le<br>
> reading larger fonts.=C2=A0 The line width usable by someone with a 32=
-inch<br>
> monitor on their desk who is comfortable with 10 point type is a LOT<b=
r>
> bigger than the line width usable by someone with a 14-inch laptop who=
<br>
> is more comfortable with 14-point type (who also has to keep a margin<=
br>
> clear for the Dock or its equivalent).=C2=A0 (Yes, I could buy a 32-in=
ch<br>
> HDMI monitor that would plug into my laptop.=C2=A0 As it happens, I di=
d.<br>
> But the point of a laptop is to be able to use it in places like the<b=
r>
> local Chinese Garden, for which I have a season ticket, where I can=
9;t<br>
> plug the outboard monitor in.)<br>
><br>
> So when choosing your line length, please consider<br>
>=C2=A0 - people with 14-inch laptop screens<br>
>=C2=A0 - who need a larger font than you do<br>
>=C2=A0 - who are NOT familiar with your code and need to do a lot of se=
arching<br>
>=C2=A0 - and really need to have multiple documents (use + definition, =
use<br>
> or definition + documentation)<br>
>=C2=A0 =C2=A0 open at the same time.<br>
><br>
><br>
> On Thu, 22 Jan 2026 at 00:49, Julien Fischer <<a href=3D"mailto:jfi=
[email protected]" target=3D"_blank" style=3D"">[email protected]</a>&=
gt; wrote:<br>
>><br>
>> Hi Ralph,<br>
>><br>
>> On Wed, 21 Jan 2026 at 17:30, Ralph Becket <<a href=3D"mailto:r=
[email protected]" target=3D"_blank" style=3D"">[email protected]=
m</a>> wrote:<br>
>> ><br>
>> > Happy New Year!<br>
>><br>
>> Happy new year to you too!<br>
>><br>
>> > About twenty years back, when I left Mercury to start in main=
stream commercial programming, monitors were a lot narrower.=C2=A0 There wa=
s a strong feeling then that 80 columns was the Right and Proper Line Lengt=
h.=C2=A0 Nowadays, of course, monitors are much more generous.=C2=A0 While =
I reject uncontrolled line lengths, 80 columns seems painfully tight.=C2=A0=
(I think the Linux developers moved away from this some years<br>
>> ago).=C2=A0 That said, when (back) in Rome, do as the Romans do.=
=C2=A0 So:<br>
>> what's the modern community position on this?<br>
>><br>
>> In the Mercury project itself, it's still 80 columns (actually=
79, due<br>
>> to diff adding an extra character).<br>
>><br>
>> Outside of Mercury, I tend not to go beyond that too much (unless<=
br>
>> horribly verbose things like Java<br>
>> are involved).<br>
>><br>
>> Julien.<br>
>> _______________________________________________<br>
>> users mailing list<br>
>> <a href=3D"mailto:[email protected]" target=3D"_blank" s=
tyle=3D"">[email protected]</a><br>
>> <a href=3D"https://lists.mercurylang.org/listinfo/users" rel=3D"no=
referrer" target=3D"_blank" style=3D"">https://lists.mercurylang.org/listin=
fo/users</a><br>
> _______________________________________________<br>
> users mailing list<br>
> <a href=3D"mailto:[email protected]" target=3D"_blank" style=
=3D"">[email protected]</a><br>
> <a href=3D"https://lists.mercurylang.org/listinfo/users" rel=3D"norefe=
rrer" target=3D"_blank" style=3D"">https://lists.mercurylang.org/listinfo/u=
sers</a></font><br>
</blockquote></div></div>
</div>
--000000000000762fce06490cb52f--
--===============5180192113179540735==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXNlcnMgbWFp
bGluZyBsaXN0CnVzZXJzQGxpc3RzLm1lcmN1cnlsYW5nLm9yZwpodHRwczovL2xpc3RzLm1lcmN1
cnlsYW5nLm9yZy9saXN0aW5mby91c2Vycwo=
--===============5180192113179540735==--