Long identifiers, poor readability

[Jouko Koski]

What is your preferred method for tackling the lavishly long identifiers
that seem to dominate C++ code?

C++ does not have packages or modules. Identifiers are visible in the
header files so that one has to be very careful with namespace aliases
and using directives.

After spending a while with old cut and dry C code some C++ code like

std::function<void(boost::asio::ip::tcp::socket&&)> server;

or

socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
[ptr](boost::system::error_code const& ec, std::size_t n) {

feels rather hard to read.

--
Jouko

[Marcel Mueller]

On 20.04.18 18.43, Jouko Koski wrote:
> What is your preferred method for tackling the lavishly long identifiers
> that seem to dominate C++ code?

using namespace ...

> C++ does not have packages or modules. Identifiers are visible in the
> header files so that one has to be very careful with namespace aliases
> and using directives.

At the top level scope: yes.
In nested scopes this is no real problem.

> After spending a while with old cut and dry C code some C++ code like
>
> std::function<void(boost::asio::ip::tcp::socket&&)> server;
>
> or
>
> socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
> [ptr](boost::system::error_code const& ec, std::size_t n) {
>
> feels rather hard to read.

Feel free to write smarter code. ;-)


Marcel

[Jouko Koski]

"Marcel Mueller" wrote:

> On 20.04.18 18.43, Jouko Koski wrote:
>> What is your preferred method for tackling the lavishly long identifiers
>> that seem to dominate C++ code?
>
> using namespace ...

Can you give some example, because:

>> C++ does not have packages or modules. Identifiers are visible in the
>> header files so that one has to be very careful with namespace aliases
>> and using directives.
>
> At the top level scope: yes.
> In nested scopes this is no real problem.

So, everything I write shall go to some dedicated namespace where I do
"using" for all the things I need? Then all the users of my code will
get them too. Ok, but then I apparently can to do yet another nesting
level and do "using" only for my own identifiers to pull them to the
outer level for everyone else. Is that the solution?

>> After spending a while with old cut and dry C code some C++ code like
>>
>> std::function<void(boost::asio::ip::tcp::socket&&)> server;
>>
>> or
>>
>> socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
>> [ptr](boost::system::error_code const& ec, std::size_t n) {
>>
>> feels rather hard to read.
>
> Feel free to write smarter code. ;-)

I would be glad to. Can you recommend any specific language?

--
Jouko

[Ian Collins]

On 04/21/2018 07:41 AM, Jouko Koski wrote:
> "Marcel Mueller" wrote:
>
>> On 20.04.18 18.43, Jouko Koski wrote:
>>> What is your preferred method for tackling the lavishly long identifiers
>>> that seem to dominate C++ code?
>>
>> using namespace ...
>
> Can you give some example, because:

For you later example,

namespace tcp = boost::asio::ip::tcp;

std::function<void(tcp::socket&&)> server;

Would help.

boost::asio is a pathological case for nested namespaces!

--
Ian.

[Drew Lawson]

In article <%MoCC.1004$9K9...@uutiset.elisa.fi>

"Jouko Koski" <joukokos...@netti.fi> writes:
>
>After spending a while with old cut and dry C code some C++ code like
>
>std::function<void(boost::asio::ip::tcp::socket&&)> server;
>
>or
>
>socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
>[ptr](boost::system::error_code const& ec, std::size_t n) {
>
>feels rather hard to read.

While I tend to agree, using boost examples is pretty unfair. The
boost camp has an insane love of deeply nested namespaces. Not
much of the code I deal with goes deeper than:

namespace::class::routine_or_type

I find the syntax unpleasant to read, but the benefits outweigh that.

--
Drew Lawson | I told them we had learned to change
| our swordblades into plows.
| I told them they should learn from us
| what should I tell them now?

[Jorgen Grahn]

On Fri, 2018-04-20, Ian Collins wrote:
> On 04/21/2018 07:41 AM, Jouko Koski wrote:
>> "Marcel Mueller" wrote:
>>
>>> On 20.04.18 18.43, Jouko Koski wrote:
>>>> What is your preferred method for tackling the lavishly long identifiers
>>>> that seem to dominate C++ code?
>>>
>>> using namespace ...
>>
>> Can you give some example, because:
>
> For you later example,
>
> namespace tcp = boost::asio::ip::tcp;
>
> std::function<void(tcp::socket&&)> server;
>
> Would help.

IIRC, there are also other long incantations like this in boost::asio,
so he may have to do a few of those.

> boost::asio is a pathological case for nested namespaces!

Yes. It's unclear to me if the OP has problems specifically with
boost::asio (understandable!) or also with more normal examples of
namespaces.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Juha Nieminen]

Jouko Koski <joukokos...@netti.fi> wrote:
> After spending a while with old cut and dry C code some C++ code like
>
> std::function<void(boost::asio::ip::tcp::socket&&)> server;
>
> or
>
> socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
> [ptr](boost::system::error_code const& ec, std::size_t n) {
>
> feels rather hard to read.

I actually find those easier to understand because the names are very
self-documenting. They are telling me what those names 'function',
'socket', 'buffer', and 'error_code' are (or, more precisely, which
library they belong to, and where to look for their documentation
if I don't know what they do.)

If you had written, for instance, "buffer(output.buf + output.len, n)",
I wouldn't even know that it's a Boost function. It could be anything.
It might not even become apparent with the whole source file.

[Jouko Koski]

Having to repeat the namespace name everywhere does not improve readability.
It adds noise, induces boilerplate typing and it looks ugly, albeit it does
make the identifiers more explicit.

For instance, it would be nice to have a sane way of doing

struct thing {
void func(string s);
};

so that string would be std::string in this interface without leaking the
same using or alias declaration to everywhere else, too. Any suggestions?

--
Jouko

[Jouko Koski]

"Juha Nieminen" wrote:

> Jouko Koski <joukokos...@netti.fi> wrote:

>> socket.async_write_some(boost::asio::buffer(output.buf + output.len, n),
>> [ptr](boost::system::error_code const& ec, std::size_t n) {

> I actually find those easier to understand because the names are very
> self-documenting. They are telling me what those names 'function',
> 'socket', 'buffer', and 'error_code' are (or, more precisely, which
> library they belong to, and where to look for their documentation
> if I don't know what they do.)
>
> If you had written, for instance, "buffer(output.buf + output.len, n)",
> I wouldn't even know that it's a Boost function. It could be anything.
> It might not even become apparent with the whole source file.

When examined in isolation, yes. However, this pattern does often
repeat and it becomes a tedious pain in the neck.

I tend to think that the code is usually examined in some cognitive
scope where there should be some decent way of not assuming that
anything can be just anything, other than always repeating the full
name path.

--
Jouko

[Alf P. Steinbach]

struct thing
{
using string = std::string;
void func( string const& );
};

?

Cheers!,

- Alf

[James Kuyper]

On 04/28/2018 07:11 AM, Jouko Koski wrote:
...

> Having to repeat the namespace name everywhere does not improve readability.
> It adds noise, induces boilerplate typing and it looks ugly, albeit it does
> make the identifiers more explicit.
>
> For instance, it would be nice to have a sane way of doing
>
> struct thing {
> void func(string s);
> };
>
> so that string would be std::string in this interface without leaking the
> same using or alias declaration to everywhere else, too. Any suggestions?

Can you suggest an alternative, and define the details of how you think
this alternative should work?

[Jorgen Grahn]

On Sat, 2018-04-28, Jouko Koski wrote:
> "Jorgen Grahn" wrote:
>>On Fri, 2018-04-20, Ian Collins wrote:
>>> boost::asio is a pathological case for nested namespaces!
>>
>> Yes. It's unclear to me if the OP has problems specifically with
>> boost::asio (understandable!) or also with more normal examples of
>> namespaces.
>
> Having to repeat the namespace name everywhere does not improve readability.
> It adds noise, induces boilerplate typing and it looks ugly, albeit it does
> make the identifiers more explicit.

Then I'm with Juha (I think it was): I think accepting the namespaces
is the best overall solution. So I refer to things as "std::foo" and
to "bar::foo" in my code (if that code isn't also in bar).

It no longer looks ugly to me, and it typically doesn't mean a lot of
repetition (especially nowadays with C++11 auto).

I've done some work with boost::asio, and there the long namespacing
/was/ annoying, because you had to mention it over and over again.

> For instance, it would be nice to have a sane way of doing
>
> struct thing {
> void func(string s);
> };
>
> so that string would be std::string in this interface without leaking the
> same using or alias declaration to everywhere else, too. Any suggestions?

If we focus on the interface: to me, if that had appeared in a header
file, I'd worry about what 'string' meant, since it didn't say
'std::string'. It doesn't feel like an improvement to

struct thing {
void func(std::string s);
};

I can appreciate an abbreviation like this in an interface:

using ResolverMap = std::map<std::string, std::list<IpAddress>>;

but then I'm getting something more than removal of the std prefix.

[woodb...@gmail.com]

I would write it like this:

using ResolverMap = ::std::map<::std::string,::std::list<IpAddress>>;

.

>
> but then I'm getting something more than removal of the std prefix.
>

You get both precise and flexible names this way.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Jouko Koski]

Yes, and a typedef would do as well. Now, can this be scaled so that
other identifiers from or even the whole std:: would be available inside
the struct?

--
Jouko

[Jouko Koski]

I thought I was asking the question. :-) Well, the ultimate goal is to
improve readability in a bit broader context than in an interface
consisting of one class with one member function. But these would be my
shots with this minimalistic example so far:

using namespace std; // considered bad

struct thing {
void func(string s);
};

This is the non-solution, because it leaks std to anybody using the thing.

struct thing {
typedef std::string string; // or using string = std::string;
void func(string s);
};

This is a solution. However, it does not scale, because a typedef is
necessary for each "beautified" type in the class scope. The solution
carries a lot of boilerplate: We have written "string" three times!

struct thing {
using namespace std; // not valid C++
void func(string s);
};

If this were allowed it would probably the best solution. But there
might be some implications...

namespace some_unique_boilerplate_namespace_name {
using namespace std;

struct thing {
void func(string s);
};
}

using some_unique_boilerplate_namespace_name::thing;

This is the best I have come up with. But shall we really conclude
that the general guideline is: Place all your code in a namespace
even when you are not supposed to use a namespace; and place all your
code in a nested namespace when you are using a namespace?

--
Jouko

[Jouko Koski]

"Jorgen Grahn" wrote:
> On Sat, 2018-04-28, Jouko Koski wrote:

>> Having to repeat the namespace name everywhere does not improve
>> readability.
>> It adds noise, induces boilerplate typing and it looks ugly, albeit it
>> does
>> make the identifiers more explicit.
>
> Then I'm with Juha (I think it was): I think accepting the namespaces
> is the best overall solution. So I refer to things as "std::foo" and
> to "bar::foo" in my code (if that code isn't also in bar).

Making a virtue of necessity! Yes, it is more explicit, but it cripples
readability.

> It no longer looks ugly to me, and it typically doesn't mean a lot of
> repetition (especially nowadays with C++11 auto).

Well, it is ugly and there is still a lot of repetition.

>> struct thing {
>> void func(string s);
>> };

> If we focus on the interface: to me, if that had appeared in a header
> file, I'd worry about what 'string' meant, since it didn't say
> 'std::string'.

I trust you not being that inept in real life! People using some other
languages that have packages or modules mechanism seem to do quite ok
with this issue.

If there were "string", "buffer" or "socket" in some declaration and
there is "std" or "boost::asio" in the same cognitive scope, one should
be able to assume that string, buffer or socket cannot be just anything.
They are supposed to be coming from std or boost::asio without the need
of repeating the full namespace path on every single occurrence.

When it comes to this particular toy example, string is probably the
most used type in the standard library. I would expect that if there
were any other kind of string in the same context simultaneously, it
is that string that should be addressed as the other::string without
having to drag the std:: prefix to everywhere else. Having "using
namespace std;" in the global scope might not be that bad idea after
all but that is another story.

> I can appreciate an abbreviation like this in an interface:
>
> using ResolverMap = std::map<std::string, std::list<IpAddress>>;
>
> but then I'm getting something more than removal of the std prefix.

Yes. When it comes to code readability, this declaration is over 60
characters long. It is a bit challenging to try to limit the max line
length to 80 when this kind of stuff tends to be the norm. About 10 %
of it is colons and the "std::" is repeated three times. That resembles
noise.

--
Jouko

[Jouko Koski]

wrote:

> I would write it like this:
>
> using ResolverMap = ::std::map<::std::string,::std::list<IpAddress>>;

Now, this is plain unbeliavable madness! This may solve some problem,
but that problem has very little to do with programming. A code review
with professional programmers or other professional help might give
guidance realizing that this kind of a convention results in just a
pile of personal read-only code.

--
Jouko

[Ian Collins]

All of the superfluous colons do make it had to read, take them away and
it isn't as bad....

--
Ian.

[Jorgen Grahn]

On Sun, 2018-04-29, Jouko Koski wrote:
> "Jorgen Grahn" wrote:
>> On Sat, 2018-04-28, Jouko Koski wrote:
>
>>> Having to repeat the namespace name everywhere does not improve
>>> readability.
>>> It adds noise, induces boilerplate typing and it looks ugly, albeit it
>>> does
>>> make the identifiers more explicit.
>>
>> Then I'm with Juha (I think it was): I think accepting the namespaces
>> is the best overall solution. So I refer to things as "std::foo" and
>> to "bar::foo" in my code (if that code isn't also in bar).
>
> Making a virtue of necessity! Yes, it is more explicit, but it cripples
> readability.
>
>> It no longer looks ugly to me, and it typically doesn't mean a lot of
>> repetition (especially nowadays with C++11 auto).
>
> Well, it is ugly and there is still a lot of repetition.

I note that I wrote "looks ugly to me", and that you still pretend
your preferences are universal.

>>> struct thing {
>>> void func(string s);
>>> };
>
>> If we focus on the interface: to me, if that had appeared in a header
>> file, I'd worry about what 'string' meant, since it didn't say
>> 'std::string'.
>
> I trust you not being that inept in real life!

Ad hominem this soon? I have better things to do.

*plonk*

[Vir Campestris]

On 29/04/2018 19:13, Jouko Koski wrote:
> "Jorgen Grahn" wrote:

>> I can appreciate an abbreviation like this in an interface:
>>
>>   using ResolverMap = std::map<std::string, std::list<IpAddress>>;
>>
>> but then I'm getting something more than removal of the std prefix.
>
> Yes. When it comes to code readability, this declaration is over 60
> characters long. It is a bit challenging to try to limit the max line
> length to 80 when this kind of stuff tends to be the norm. About 10 %
> of it is colons and the "std::" is repeated three times. That resembles
> noise.
>

Two things:

Why would I want to limit the line to 80 chars? My screen is bigger than
that, and has been for 20 years at least.

And

using ResolverMap
= std::map<
std::string,
std::list<
IpAddress
>
>;

Andy.
--
Apparently the Linux kernel standard is to stop excessive nesting. so
why doesn't it limit nesting instead?

[Juha Nieminen]

Jouko Koski <joukokos...@netti.fi> wrote:
> When examined in isolation, yes. However, this pattern does often
> repeat and it becomes a tedious pain in the neck.

Code readability requires following coding conventions. Writing namespace
prefixes can be a good coding convention.

[Paavo Helde]

On 29.04.2018 20:45, Jouko Koski wrote:
> "James Kuyper" wrote:
>> On 04/28/2018 07:11 AM, Jouko Koski wrote:
>
>>> For instance, it would be nice to have a sane way of doing
>>>
>>> struct thing {
>>> void func(string s);
>>> };
>>>
>>> so that string would be std::string in this interface without leaking
>>> the
>>> same using or alias declaration to everywhere else, too. Any
>>> suggestions?
>>
>> Can you suggest an alternative, and define the details of how you think
>> this alternative should work?
>
> I thought I was asking the question. :-) Well, the ultimate goal is to
> improve readability

One thing you forget here is that readability depends on the reader.
What is easily recognized by one reader might not be recognized by another.

If I am familiar with the codebase and know there is no custom string
class there, then seeing a type name string automatically means this
must be a std::string. If I am not familiar with the codebase, then it
is not so clear at all.

When I see an identifier like socket in some foreign or long-forgotten
code I am just trying to debug this is not readable at all. What does it
mean, how do I construct one? Man socket says it is a function.

I will need to figure out somehow that it is a
boost::asio::ip::tcp::socket (or then something else). If I read this
code once in 5 years, I would like to have it all spelled out. If I read
and write this code each day, then I want it to be shortened to just
socket. The readability goals are different.

[Jouko Koski]

"Vir Campestris" wrote:
> Two things:
>
> Why would I want to limit the line to 80 chars? My screen is bigger than
> that, and has been for 20 years at least.

80 may not be the exact value, but longer lines tend to deteriorate
readability, and that is fairly universal. Then, team members may be
reading code on paper or on their smartphones, and there are still old
vga projectors out there. Some people may be visually impaired or just
prefer to use the ample horizontal space for placing the working
windows side by side.

> And
>
> using ResolverMap
> = std::map<
> std::string,
> std::list<
> IpAddress
> >
> >;

Line folding tend to break the visual flow. Folding convention and
indentation do matter. Sometimes it may be insightful to replace all
printable characters in a source file (or in any text, for the matter!)
with X characters, and assess if the pattern still communicates
structure, function, and intent.

> Apparently the Linux kernel standard is to stop excessive nesting. so
> why doesn't it limit nesting instead?

Well, it does, doesn't it?

--
Jouko

[Ian Collins]

On 04/30/2018 08:53 AM, Vir Campestris wrote:
> On 29/04/2018 19:13, Jouko Koski wrote:
>> "Jorgen Grahn" wrote:
>>> I can appreciate an abbreviation like this in an interface:
>>>
>>>   using ResolverMap = std::map<std::string, std::list<IpAddress>>;
>>>
>>> but then I'm getting something more than removal of the std prefix.
>>
>> Yes. When it comes to code readability, this declaration is over 60
>> characters long. It is a bit challenging to try to limit the max line
>> length to 80 when this kind of stuff tends to be the norm. About 10 %
>> of it is colons and the "std::" is repeated three times. That resembles
>> noise.
>>
>
> Two things:
>
> Why would I want to limit the line to 80 chars? My screen is bigger than
> that, and has been for 20 years at least.

Some of us have very wide screens, but like to look at multiple files
side by side. Screen size and line length are unrelated.

--
Ian.

[Tim Rentsch]

Vir Campestris <vir.cam...@invalid.invalid> writes:

> On 29/04/2018 19:13, Jouko Koski wrote:
>
>> "Jorgen Grahn" wrote:
>>
>>> I can appreciate an abbreviation like this in an interface:
>>>
>>> using ResolverMap = std::map<std::string, std::list<IpAddress>>;
>>>
>>> but then I'm getting something more than removal of the std prefix.
>>
>> Yes. When it comes to code readability, this declaration is over
>> 60 characters long. It is a bit challenging to try to limit the
>> max line length to 80 when this kind of stuff tends to be the norm.
>> About 10 % of it is colons and the "std::" is repeated three times.
>> That resembles noise.
>
> Two things:
>
> Why would I want to limit the line to 80 chars?

There are good human factors reasons to limit lines to somewhere
in the neighborhood of 75 characters. It's no accident that
paper is taller than it is wide.

> My screen is bigger than that, and has been for 20 years at least.

Not really a good argument. Just because something can be done
doesn't mean it's a good idea to do it. Also there are other
output media to consider: even if you are happy to view code
only on your wide screen, other people want to look at code
using different media.

> using ResolverMap
> = std::map<
> std::string,
> std::list<
> IpAddress
> >
> >;

If it were important to write this declaration on more than one
line, I would be inclined to take more advantage of horizontal
space, reducing the amount of vertical space used:

using ResolverMap =
std::map< std::string, std::list< IpAddress > >
;

or perhaps

[James R. Kuyper]

On 04/29/2018 04:53 PM, Vir Campestris wrote:
...

> Why would I want to limit the line to 80 chars? My screen is bigger than
> that, and has been for 20 years at least.

Because scanning a long line is hard work for your eyes. There's a
reason why newspaper columns are so narrow: they're about the maximum
width that your eyes can see at one time without scanning left-to-right.
You can read a newspaper column scanning only in the vertical direction.
Books and magazines typically are wider, because it's not necessary to
completely avoid horizontal scanning. However, anything larger than
about 80 characters puts excess strain on your eye muscles - which is
why 80 characters was a popular choice for both printers and display
screens.

[Scott Lurndal]

"James R. Kuyper" <james...@verizon.net> writes:
>However, anything larger than
>about 80 characters puts excess strain on your eye muscles - which is
>why 80 characters was a popular choice for both printers and display
>screens.

And here I always though it was to match 80-column cards. And note
that printers were generally 132 columns before consumer (cheap)
printers became widely available.

[James R. Kuyper]

I'm giving part of the reason why (among other things) 80-column cards
became more popular than other sizes, and why 80 column printers became
more popular than 132 column ones.

[Scott Lurndal]

"James R. Kuyper" <james...@verizon.net> writes:
>On 04/30/2018 11:09 AM, Scott Lurndal wrote:
>> "James R. Kuyper" <james...@verizon.net> writes:
>>> However, anything larger than
>>> about 80 characters puts excess strain on your eye muscles - which is
>>> why 80 characters was a popular choice for both printers and display
>>> screens.
>>
>> And here I always though it was to match 80-column cards. And note
>> that printers were generally 132 columns before consumer (cheap)
>> printers became widely available.
>
>I'm giving part of the reason why (among other things) 80-column cards
>became more popular than other sizes

Hm. Given that interpreted cards (i.e. cards with column content printed on them)
were generally quite rare, particularly in the first half of the 20th
century, I'm not sure that eyestrain had anything to do with the choice
of 80-columns for cards.

>, and why 80 column printers became
>more popular than 132 column ones.

Again, I can't see (pun unintended) that. I can see that when
using 8.5x11 paper in a printer, portrait mode printing at 10cpi
(a readable size for most) yields 80 columns - so I think the
relationship is more about using 8.5 inch wide paper than 80 columns per-se.

[James R. Kuyper]

On 04/30/2018 11:16 AM, Stefan Ram wrote:
> "James R. Kuyper" <james...@verizon.net> writes:

>> completely avoid horizontal scanning. However, anything larger than
>> about 80 characters puts excess strain on your eye muscles - which is
>> why 80 characters was a popular choice for both printers and display
>> screens.
>

> However long a line is, it always will fit into the screen
> (when editing). Today's Screens are somewhat wider but they
> also have a higher resolution, so sometimes more characters
> fit into the same width when the width is measured by the
> arc width it has for the eye (i.e., measured in degrees).

Your eyes have much higher resolution in the fovea than in peripheral
areas, and that resolution is needed when reading densely packed text.
This isn't immediately obvious, because whenever you try to pay
attention to a part of your field of view that is not currently
projected onto your fovea, your eyes automatically move to project it
onto that area, creating the illusion that we can see at high resolution
across our entire field of view.

> And if there would be such a strain, this also would imply
> that a slideshow with pictures or a movie should not use the
> full width of the screen but be restricted to an area of
> smaller width.

As a general rule, film makers keep things that require high resolution
viewing near the center of the field of view; the edges tend to be
occupied by images for which the lower resolution of our our peripheral
vision is sufficient, either because they don't have much fine detail,
or because the fine detail isn't important.

[Robert Wessel]

On Mon, 30 Apr 2018 15:09:37 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

A major use case, perhaps *the* major use case for printers in the
early days of computing was to present data in a (more-or-less)
tabular format. That has always lent itself to wider presentations.
Just look at many of the old-fashioned paper accounting ledger books.
But that's not text-like data. Interestingly, the 17x11 inch paper
those printers spent so much time banging on is actually known as a
"ledger size" page (similar to the common 8.5x11 being a "letter size"
page).

The US letter size, and the similar international standard size (aka
A4), formats long predate modern computers, and all accommodate about
80 characters with a reasonably sized font. Of course smaller fonts
have always existed, and you could even fairly easily get typewriters
with smaller fonts (usually called an "elite" font, or some-such), but
they were fairly rare, and tended to be used more in application where
the harder to read font was a worthwhile tradeoff for the increased
presentation width.

[Richard]

[Please do not mail me a copy of your followup]

"James R. Kuyper" <james...@verizon.net> spake the secret code
<07f8c7f0-3a20-05a2...@verizon.net> thusly:

>[...] However, anything larger than

>about 80 characters puts excess strain on your eye muscles - which is
>why 80 characters was a popular choice for both printers and display
>screens.

The ergonomic case is valid, but it isn't the historical reason for
display screens at least. Many early terminals were 32 or 40 characters
per line and by the mid 60s the switch to 80 characters per line was the
defacto standard. Mostly this is due to the cost of memory, character
generators, refresh circuitry and the available resolution of cheap
CRT tubes used in black and white televisions as a ready supply of CRT
tubes for display terminals.

At some point, it became a selling point to support 132 columns for line
in display terminals so that the display matches the printed output.
However, most terminals displayed pretty crappy looking glyphs for
characters in 132 column mode. Mode 80 column terminals used pretty
crappy looking glyphs to begin with in order to reduce the cost and
complexity of character generation and refresh circuitry. A notable
exception were terminals produced by Hewlett-Packard, where they had a
bunch of tricks to get really smooth looking characters. Here are
some images for reference:
<http://hpmuseum.net/images/2645AScreen-35.jpg>
<http://hpmuseum.net/images/2622AScreen-30.jpg>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Vir Campestris]

On 30/04/2018 10:02, Jouko Koski wrote:
> "Vir Campestris" wrote:
>> Two things:
>>
>> Why would I want to limit the line to 80 chars? My screen is bigger
>> than that, and has been for 20 years at least.
>
> 80 may not be the exact value, but longer lines tend to deteriorate
> readability, and that is fairly universal. Then, team members may be
> reading code on paper or on their smartphones, and there are still old
> vga projectors out there. Some people may be visually impaired or just
> prefer to use the ample horizontal space for placing the working
> windows side by side.
>

I haven't seen anyone print any code in years (and in any case a quick
count on the nearest bit of paper indicates a line length of ~120 on an
A4 newsletter). I don't want my company secrets out on smartphones. We
don't have any VGA projectors, and don't put code up on the projectors
we have anyway. Visually impaired is a fair point - but there aren't
many visually impaired programmers. I've only met one in my entire
career. Why would I affect everyone else's productivity for the sake of
the minority? Just buy a decent 4k TV for the one with the eye problems.
I just checked my screen width - I can get about 200 chars in the window
I use here, even given the subsidiary windows beside it. And this
monitor is smaller than anything I use professionally. 200 probably is a
bit long...

>> And
>>
>> using ResolverMap
>>    = std::map<
>>        std::string,
>>        std::list<
>>          IpAddress
>>        >
>>      >;
>
> Line folding tend to break the visual flow. Folding convention and
> indentation do matter. Sometimes it may be insightful to replace all
> printable characters in a source file (or in any text, for the matter!)
> with X characters, and assess if the pattern still communicates
> structure, function, and intent.

That was exaggerated to make a point.

>
>> Apparently the Linux kernel standard is to stop excessive nesting. so
>> why doesn't it limit nesting instead?
>
> Well, it does, doesn't it?
>

Yes, but indirectly. You can have longer meaningful parts in lines at
the outer nesting levels. Which to me is just weird. A direct limit on
nesting would make sense to me.

Andy

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<pcakbv$buf$2...@dont-email.me> thusly:

>Visually impaired is a fair point - but there aren't
>many visually impaired programmers.

It happens to everyone if they live long enough.