Re: Which code style do you prefer the most?

On 27/02/2025 06:57, Janis Papanagnou wrote:

On 26.02.2025 20:56, David Brown wrote:

On 26/02/2025 18:13, Janis Papanagnou wrote:

On 26.02.2025 17:32, David Brown wrote:

On 26/02/2025 15:39, Bradley K. Sherman wrote:

Just do your best to keep it neat and under 80 columns.
>

>
Neat, yes.  80 columns, no - unless you are living in the previous
century.

>
That's the typical response of someone who obviously doesn't care. :-/
>

>
I care about legibility of code, and convenience of working with it.  I
don't care how well it fits in a text-only screen that is limited by
ancient hardware.

 Wherever and whenever it originated is not the question. - Here I was
just pointing out that "living in the previous century" is a typical
response of someone who obviously isn't much interested in rationales
and in discussions of these. We've heard that regularly, just recently
for example in context of "ancient editors". If there were interest we
would discuss it differently.

Ah, okay, I see what you mean.  Yes, I used "emotive language" to emphasise my dislike for decisions that are based /solely/ on "we've always done it that way" or "that's what other people do".  These can be relevant factors in a decision - there's always a cost in changing things or picking unusual solutions, and that must be weighed against benefits from doing things differently.  But they should not be overriding factors - unfortunately, often people treat them that way.
There is no implication in what I wrote, or the way I wrote it, that I don't care.  Indeed, the implication from my language is that I /do/ care - I care enough to mock those who don't care and don't consider such things (code style, in this case) but merely stick to old habits without thought.

 So lets see what follows... :-)
 

I do plenty from the command-line, but if I am
working with a file from the command line, it is almost invariably under
a gui - terminal windows can be sized for convenience.
>

[...]

>
This sounds more reasonable. :-)
>
[...]

>
Too long lines are hard to read.  Too short lines are hard to read.

 Yes, I agree.
 

80 columns is not a terrible choice, but it is too often too short,
especially if you try to view it as a hard limit.

 Since decades now there are no such hard limits, so why do you make
up such a statement.

That's exactly the point - there /are/ no real hard limits, and have not been any since we moved on from pure text-mode terminals.  Some situations have short line limits (such as for a slideshow in a presentation), most situations for normal coding can be as wide as the developer finds convenient.
So why do some people think that 80 columns should be a hard limit to their line length?  They do not, for the most part, think 80 characters is ideal for readability, or for display, or for printing, or for writing code, or for reviewing it, or for any other use.  For the most part, they don't think at all.  They simply regurgitate 80 columns because IBM picked 80 columns as the width of punched cards in 1928.  If IBM had picked 72 columns or 96 columns, Bradley would have written "Just do your best to keep it neat and under 72 columns" or "Just do your best to keep it neat and under 96 columns".
If a particular person has good, technical reasons for picking 80 columns as a limit - or indeed, for picking a hard limit at all - then that's fair enough.  If a person sees a strong advantage in having a fixed limit, and concludes (based on their real code needs) that they often need lines more than 60 characters but very rarely want more than 80, and thus sets their limit at 80 - then fair enough.

 

  [...]

>
Too short identifiers are bad - too long identifiers are bad.

 Yes, as a rule of thumb, I agree.
 Though it doesn't hold as sort of a general truth, because...

It /does/ hold as a general truth, with the implicit context added.

 

>
Generally, identifier length should be roughly related to the size of
their scope.

 ...of that. - I agree.
 

>

  From typesetting we know that long lines are bad to read; why are
the newspaper columns so narrow?

>
Newspaper columns are hard to read well - they are narrow because
newspapers are often trying to put a lot of stuff on one page despite it
being less legible.

 I take this as your opinion.
 

OK.
 > In newspapers you can find articles that can span even a whole page.
 > It's nonetheless organized in small columns.
Of course different newspapers do things differently.
And maybe there are other reasons for having columns that are often far too narrow for legibility, sometimes leading to horrible inconsistent spacing, really messy hyphenation, and the like.
Columns are clearly required for newspapers - the pages are (usually) far too wide to be comfortable to read without splitting up into columns.  The question is what width they should be.
Generally, around 60 - 70 characters is common for quick, easy reading, such as most books.  Technical documents can have a good deal more - a quick check suggests that the C standards have around 90 characters per line, while the C++ standards (with a smaller typeface) have about 105. A technical white paper that I happen to have open at the moment has 120 character lines.
Newspaper columns are often much shorter - 30 to 40 characters.  So why is that?
The prime purpose of a newspaper is, obviously, to make money.  The more you put in the same area, the better.  Having regular column sizes reduces costs (especially before computer-based layout and printing). It makes it easier to sell advertising space.
Modern newspapers can be more flexible in their layouts, but keeping a familiar look is important.  Legibility of individual columns of text is much less important - after all, most readers scan headlines and only read a small proportion of the column text.

 

>
The "ideal" length for prose will vary depending on the kind of text,
the language, the size and style of the font, the general layout, the
medium, and other factors.

 Right.
 

Somewhere between about 60 and 100 characters is typical.

 These numbers appear strange to me. - A quick look into a couple of
different editions show more like 45-90 characters, with typical
values around 55-70 (including spaces counted as characters), i.e.
not in the extreme ranges. For these numbers I've inspected random
books written in different layouts, in three different languages,
and of different types. - I would be very astonished if that would
be fundamentally different in your language domain, but YMMV.
 

What did you actually look at?  Novels?  Textbooks?  Documents written for A4 page sizes?  Newspapers?  Old legal documents?

So I have to conclude that printed typical text would fit regularly
and easily in an 80 column mono-spaced medium.
 

Your conclusion would be wrong, unless you are limiting it to specific areas.  (The word "typical" is very vague.)

>

Long lines are even worse to read if you use sans-serif fonts;
too bad that such bad fonts are dominating our modern world, and
especially in the IT ("thanks" MS for fostering Arial, etc.);
using less columns is also often advantageous here to compensate
the reduced legibility.
Don't expect that everyone has a screen as big as yours; that is
the case in companies but also in other places or projects where
code is shared or where people work together.
>

>
Shorter line lengths don't make it easier to work on smaller screens.  A
smaller screen means less code is visible at a time, regardless of line
length.

 It's not about "small screens"; it's about readability as being a
function of the used line-length. But readability, while probably
a most important factor, is not the only aspect...
 

I agree that readability is key here.  But remember that readability of code is not the same thing as readability of prose.  Doing too much in one line of code makes it hard to understand - regardless of how many characters it actually uses.  Taking something that is logically one operation or expression and artificially splitting it into two (or more) lines to suit an arbitrary line length limit also makes the code hard to understand.
Small screens and line length are related in that they place a physical limit on the length of a line you can have and still read easily.

Myself I usually operate on a minimum of two physical screens, and
(with my font setting) each one capable of displaying two 80-column
windows side by side.

That seems small to me.  I have no problem with two approximately 120-column windows side-by-side in my IDE, along with all the additional junk - file lists, code outlines, line numbers, scroll bars, etc. Sometimes I will have three files side-by-side, with a bit less space for the junk, depending on what I am doing.  (I usually have other stuff like command windows, serial terminals, webpages, documents, etc., on the other screens.)

I regularly work with more than one text file
in parallel, and if there's some source with significantly larger
line width I either have to scroll sidewards of have to accept line
wraps at arbitrary (typically very bad) places with all the negative
effects! It's much better to define the code layout yourself, better
for legibility in the first place, and better to work with available
typical resources.
 

Sure.  I do the same, for the same reasons.  But I don't restrict myself to so short line lengths.  (Of course most of the lines in my code are shorter than 80 characters.)

>

Myself I have the habit to take an 80 column screen as baseline,
organize my source code in that frame. But that's no credo; the
purpose is just to not let the lines get too long "by accident".
I then wrap the code at sensible places with indentation. And if
_some_ lines get longer, say your 100 or 120 columns, that's no
problem as long as the overall readability is still guaranteed.
>
Again, preferences vary, here as well.
>

>
Sure.  I am simply arguing against hard and fast rules that are not
based on hard and fast reality.

 There was no hard rule as should have been obvious by what I wrote.
 

I haven't suggested that /you/ have such a hard rule.

The 80 column rule [of thumb] is a good (empirical) base; while it
may have had its origin in historic hard limits of IT devices (like
VT100 or some such - that, BTW, are also not completely arbitrarily
chosen!) it is also a _sensible value_ given the expertise of the
printed media, and the reality of work (in the IT sector or else).
 

80 characters is not the worst rule you could pick, but it is far from optimal for lots of uses - including lots of prose, printed text, online documents, and coding.

YMMV.
 

Of course :-)