Deutsch   English   Français   Italiano  
<vpourn$30a9h$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Which code style do you prefer the most?
Date: Thu, 27 Feb 2025 06:57:10 +0100
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <vpourn$30a9h$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 27 Feb 2025 06:57:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7a301de3e08edcb10ceefde6c0f3fc75";
	logging-data="3156273"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8cy+zkTs2bIOrLqmvqHz7"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:j7Q/hk+od2CK0HgyP0UKMMqgjcY=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vpnrld$2mq8h$2@dont-email.me>
Bytes: 6914

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.

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.

>>  [...]
> 
> 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...

> 
> 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.

In newspapers you can find articles that can span even a whole page.
It's nonetheless organized in small columns.

> 
> 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.

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

> 
>> 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...

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. 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.

> 
>> 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.

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).

YMMV.

Janis