[m-users.] Coding style

[Paul Bone]

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