Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Which code style do you prefer the most?
Date: Thu, 27 Feb 2025 16:47:40 +0100
Organization: A noiseless patient Spider
Lines: 272
Message-ID: <vpq1es$35inm$1@dont-email.me>
References: <vpkmq0$21php$1@dont-email.me> <vpl62m$250af$1@dont-email.me>
 <87frk10w51.fsf@onesoftnet.eu.org> <vpn8vs$2jmv1$1@dont-email.me>
 <vpn92i$86q$1@reader1.panix.com> <vpnfmn$2ksdj$1@dont-email.me>
 <vpni33$2ld5k$1@dont-email.me> <vpnrld$2mq8h$2@dont-email.me>
 <vpourn$30a9h$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 27 Feb 2025 16:47:43 +0100 (CET)
Injection-Info: dont-email.me; posting-host="06a8019a08c63385063fcd606aa3c794";
	logging-data="3328758"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Tb0THbHqSDN/F3R26JKLYn2BCAWr89qY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:33YHbKlXF8vOSp21PbS8UI5F6e8=
In-Reply-To: <vpourn$30a9h$1@dont-email.me>
Content-Language: en-GB
Bytes: 12655

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.
========== REMAINDER OF ARTICLE TRUNCATED ==========