Overuse of 'auto'
595 views
Skip to first unread message
Juha Nieminen
Dec 8, 2022, 7:32:04 AM12/8/22
to
During the last few years I have had to read an inordinate amount of
code written by other people. It has really given me a big insight on
what makes code more and less readable and understandable. For example,
I could write an entire book on naming conventions alone, and how they
can make the code so much more readable, or make it almost inscrutable.
But another thing I have really learned to hate is the overuse of the
'auto' keyword. I have always opposed its needless overuse, but this
couple of years of reading other people's code has really confirmed
and cemented my previous opinion on it.
Some C++ programmers do not use 'auto' merely to save some typing,
as some kind of convenience feature. They go their way to use it
pretty much everywhere they can, even when it doesn't actually save
any typing or make anything more convenient. They use it like it were
the generic variable declaration keyword in many other languages
(quite typically "var").
The problem in using 'auto' everywhere, from the perspective of someone
who is reading the code, is that it hides the type in question. When
you see something like:
auto foobar = someFunction(a, b);
it's a complete mystery what that return type is, and thus the reader
(ie. me) has no idea what it actually is, what it does, and how it's
used. Could be an 'int', could be a 'double', could be a 'std::string',
or could be a custom type declared somewhere else in the program. That
line alone doesn't clarify. Quite often even subsequent lines of code
don't necessarily clarify.
It just makes code so much harder to read when this crucial information
has been hidden from you. This is not really what "information hiding"
should be about.
"Yada yada! Just use an IDE like everybody else does!"
Even putting aside the fact that well-written code shouldn't rely on the
reader using an IDE to understand it, there are many situations where
you don't have a fancy IDE to tell you what that type is, or where it
can be found, such as for example when reading and reviewing the code
in gitlab. Try reviewing code when you can't even see what the types
being used are.
Man, have I learned to hate the overuse of 'auto'...
code written by other people. It has really given me a big insight on
what makes code more and less readable and understandable. For example,
I could write an entire book on naming conventions alone, and how they
can make the code so much more readable, or make it almost inscrutable.
But another thing I have really learned to hate is the overuse of the
'auto' keyword. I have always opposed its needless overuse, but this
couple of years of reading other people's code has really confirmed
and cemented my previous opinion on it.
Some C++ programmers do not use 'auto' merely to save some typing,
as some kind of convenience feature. They go their way to use it
pretty much everywhere they can, even when it doesn't actually save
any typing or make anything more convenient. They use it like it were
the generic variable declaration keyword in many other languages
(quite typically "var").
The problem in using 'auto' everywhere, from the perspective of someone
who is reading the code, is that it hides the type in question. When
you see something like:
auto foobar = someFunction(a, b);
it's a complete mystery what that return type is, and thus the reader
(ie. me) has no idea what it actually is, what it does, and how it's
used. Could be an 'int', could be a 'double', could be a 'std::string',
or could be a custom type declared somewhere else in the program. That
line alone doesn't clarify. Quite often even subsequent lines of code
don't necessarily clarify.
It just makes code so much harder to read when this crucial information
has been hidden from you. This is not really what "information hiding"
should be about.
"Yada yada! Just use an IDE like everybody else does!"
Even putting aside the fact that well-written code shouldn't rely on the
reader using an IDE to understand it, there are many situations where
you don't have a fancy IDE to tell you what that type is, or where it
can be found, such as for example when reading and reviewing the code
in gitlab. Try reviewing code when you can't even see what the types
being used are.
Man, have I learned to hate the overuse of 'auto'...
Bo Persson
Dec 8, 2022, 9:25:48 AM12/8/22
to
On 2022-12-08 at 13:31, Juha Nieminen wrote:
> During the last few years I have had to read an inordinate amount of
> code written by other people. It has really given me a big insight on
> what makes code more and less readable and understandable. For example,
> I could write an entire book on naming conventions alone, and how they
> can make the code so much more readable, or make it almost inscrutable.
>
> But another thing I have really learned to hate is the overuse of the
> 'auto' keyword. I have always opposed its needless overuse, but this
> couple of years of reading other people's code has really confirmed
> and cemented my previous opinion on it.
>
> Some C++ programmers do not use 'auto' merely to save some typing,
> as some kind of convenience feature. They go their way to use it
> pretty much everywhere they can, even when it doesn't actually save
> any typing or make anything more convenient. They use it like it were
> the generic variable declaration keyword in many other languages
> (quite typically "var").
>
> The problem in using 'auto' everywhere, from the perspective of someone
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b);
>
Of course "overuse" is always bad, by definition. :-)
> During the last few years I have had to read an inordinate amount of
> code written by other people. It has really given me a big insight on
> what makes code more and less readable and understandable. For example,
> I could write an entire book on naming conventions alone, and how they
> can make the code so much more readable, or make it almost inscrutable.
>
> But another thing I have really learned to hate is the overuse of the
> 'auto' keyword. I have always opposed its needless overuse, but this
> couple of years of reading other people's code has really confirmed
> and cemented my previous opinion on it.
>
> Some C++ programmers do not use 'auto' merely to save some typing,
> as some kind of convenience feature. They go their way to use it
> pretty much everywhere they can, even when it doesn't actually save
> any typing or make anything more convenient. They use it like it were
> the generic variable declaration keyword in many other languages
> (quite typically "var").
>
> The problem in using 'auto' everywhere, from the perspective of someone
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b);
>
But here the problem could also be the use of names such as foobar and
someFunction. Why do they not tell what is happening?!
When I see code like
auto iter = container.begin();
I know that auto means "some kind of iterator", and don't really care
about exactly which one it is.
And if it is
auto size = user_name.size();
it doesn't help a bit if auto is replaced by size_type, because what
type is size_type **really**?!
Perhaps if we see auto as an automatic typedef, we can hate it less?
Mut...@dastardlyhq.com
Dec 8, 2022, 10:48:24 AM12/8/22
to
On Thu, 8 Dec 2022 12:31:48 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Some C++ programmers do not use 'auto' merely to save some typing,
>as some kind of convenience feature. They go their way to use it
>pretty much everywhere they can, even when it doesn't actually save
>any typing or make anything more convenient. They use it like it were
>the generic variable declaration keyword in many other languages
>(quite typically "var").
To be fair you could use the same argument about templating. Many times
Juha Nieminen <nos...@thanks.invalid> wrote:
>Some C++ programmers do not use 'auto' merely to save some typing,
>as some kind of convenience feature. They go their way to use it
>pretty much everywhere they can, even when it doesn't actually save
>any typing or make anything more convenient. They use it like it were
>the generic variable declaration keyword in many other languages
>(quite typically "var").
I've seem a template function thats only ever used for 2 different types.
Öö Tiib
Dec 8, 2022, 10:59:58 AM12/8/22
to
can return. Some are not possible to express. Like in functional
programming:
auto ret_fun() { return [](int x) { return x; }; }
auto& int_returner = ret_fun();
Should I wrap the return value into std::function<int(int)> to have it possible
to express its type? Is that free or brings some overhead? What if there
is combo of templates that accept as arguments and return lambdas?
Mr Flibble
Dec 8, 2022, 2:30:08 PM12/8/22
to
what? 2 > 1. Why? Because code duplication is bad even if there is only
one duplicate. You seem to be fractally wrong about most things.
/Flibble
Juha Nieminen
Dec 9, 2022, 7:52:59 AM12/9/22
to
Mut...@dastardlyhq.com wrote:
> To be fair you could use the same argument about templating. Many times
> I've seem a template function thats only ever used for 2 different types.
Incidentally, one of the things I have learned to hate when reading other
> To be fair you could use the same argument about templating. Many times
> I've seem a template function thats only ever used for 2 different types.
people's code (and which I could write an entire book about), is useless
function overloading that serves no purpose.
Way too often do you see code out there that overloads a function for
different types even though there's literally no technical reason nor
any sort of advantage in overloading it. It's done purely as a naming
thing, and that's it. There's no technical reason or purpose behind it.
You wouldn't believe, just like with the over-use of 'auto', how
frustratingly difficult it can be to read code that uses too much
function overloading at the expense of code readability and
understandability. That's because excessive overloading tends to
mean that the function name doesn't tell very explicitly what
it's doing, because the same name is being used for a myriad of
different types. Not only can this cause ambiguity from the
compiler's perspective, but it very much can cause ambiguity for the
person who is reading the code.
My personal opinion is: In the vast, vast majority of cases write
distinct function names for each distinct function (and the function
name should be quite clear about what it's doing, and how what
it's doing is different from the other functions that you would
have overloaded otherwise), and if you really, really need to
overload the function for some reason (eg. because the function is
being used in templated code), implement the overloads separately
and make them call the distinctively-named versions. And always use
the distinctively-named versions in your code unless there's an actual
good reason to use the overloaded versions. Readability is more important
than convenience.
Juha Nieminen
Dec 9, 2022, 7:56:48 AM12/9/22
to
Öö Tiib <oot...@hot.ee> wrote:
> Yes but it is tedious. Some types are *LONG*, especially what templates
> can return.
So what? I very much oppose the brevity-over-clarity style of programming.
> Yes but it is tedious. Some types are *LONG*, especially what templates
> can return.
What exactly are you saving by shortening names (especially if shortening
them to something that tells absolutely nothing about the actual type)?
Disk space? Or are you really in such a hurty that you can't spend a few
seconds typing the longer name?
> Some are not possible to express. Like in functional
> programming:
they don't have a named type and that the only way to handle them is
with 'auto'.
In this case there's a good *technical* reason to use 'auto'. It's
not merely used for convenience or avoiding writing a couple of extra
characters.
Michael S
Dec 9, 2022, 8:03:47 AM12/9/22
to
Few more years and you'll start to agree with your famous former compatriot.
"C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.".
https://lwn.net/Articles/249460/
Scott Lurndal
Dec 9, 2022, 9:16:06 AM12/9/22
to
Mut...@dastardlyhq.com
Dec 9, 2022, 10:52:29 AM12/9/22
to
Öö Tiib
Dec 9, 2022, 10:57:47 AM12/9/22
to
On Friday, 9 December 2022 at 14:56:48 UTC+2, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Yes but it is tedious. Some types are *LONG*, especially what templates
> > can return.
> So what? I very much oppose the brevity-over-clarity style of programming.
>
> What exactly are you saving by shortening names (especially if shortening
> them to something that tells absolutely nothing about the actual type)?
> Disk space? Or are you really in such a hurty that you can't spend a few
> seconds typing the longer name?
I was not talking about "name" but "type" with number of template
> Öö Tiib <oot...@hot.ee> wrote:
> > Yes but it is tedious. Some types are *LONG*, especially what templates
> > can return.
> So what? I very much oppose the brevity-over-clarity style of programming.
>
> What exactly are you saving by shortening names (especially if shortening
> them to something that tells absolutely nothing about the actual type)?
> Disk space? Or are you really in such a hurty that you can't spend a few
> seconds typing the longer name?
arguments some of what are also templates and nested.The simpler
cases are almost tolerable but real types to deal with get hairy fast:
std::map<std::string_view, std::function<int(void)>>::insert_return_type
That when one should know fully well what map::insert returns
pair of its iterator and bool.
> > Some are not possible to express. Like in functional
> > programming:
> C++ lambdas are special in that the standard explicitly states that
> they don't have a named type and that the only way to handle them is
> with 'auto'.
>
> In this case there's a good *technical* reason to use 'auto'. It's
> not merely used for convenience or avoiding writing a couple of extra
> characters.
Ben Bacarisse
Dec 9, 2022, 12:44:44 PM12/9/22
to
Juha Nieminen <nos...@thanks.invalid> writes:
> 嘱 Tiib <oot...@hot.ee> wrote:
>> Yes but it is tedious. Some types are *LONG*, especially what templates
>> can return.
>
> So what? I very much oppose the brevity-over-clarity style of
> programming.
As usual, such rules oversimplify the issues. Sometime clarity can
actually come from brevity.
It's usually more enlightening to give what you consider good and bad
examples as well some examples on the boundary. For example, I rarely
want to know more about the type when I see
for (const auto &elem : <something>) ...
Where in your spectrum of clarity vs. brevity does this sort of use come?
--
Ben.
> 嘱 Tiib <oot...@hot.ee> wrote:
>> Yes but it is tedious. Some types are *LONG*, especially what templates
>> can return.
>
> So what? I very much oppose the brevity-over-clarity style of
> programming.
actually come from brevity.
It's usually more enlightening to give what you consider good and bad
examples as well some examples on the boundary. For example, I rarely
want to know more about the type when I see
for (const auto &elem : <something>) ...
Where in your spectrum of clarity vs. brevity does this sort of use come?
--
Ben.
Andreas Dehmel
Dec 9, 2022, 3:03:23 PM12/9/22
to
On Fri, 09 Dec 2022 17:44:27 +0000
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
I'd say it's on the lowest end of the spectrum. As soon as people start
decorating their "auto" with things like "const", "*" or "&" it
_always_ is. Either the type is self-explanatory or irrelevant, in
which case plain "auto" will do, or it isn't, in which case "auto" is
conceptually wrong. Decorating "auto" like that is just a pathetic
attempt at hiding this simple fact.
Andreas
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
decorating their "auto" with things like "const", "*" or "&" it
_always_ is. Either the type is self-explanatory or irrelevant, in
which case plain "auto" will do, or it isn't, in which case "auto" is
conceptually wrong. Decorating "auto" like that is just a pathetic
attempt at hiding this simple fact.
Andreas
Ben Bacarisse
Dec 9, 2022, 3:47:48 PM12/9/22
to
Andreas Dehmel <blackhole....@spamgourmet.com> writes:
> On Fri, 09 Dec 2022 17:44:27 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
> On Fri, 09 Dec 2022 17:44:27 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>> > 嘱 Tiib <oot...@hot.ee> wrote:
>> >> Yes but it is tedious. Some types are *LONG*, especially what
>> >> templates can return.
>> >
>> > So what? I very much oppose the brevity-over-clarity style of
>> > programming.
>>
>> As usual, such rules oversimplify the issues. Sometime clarity can
>> actually come from brevity.
>>
>> It's usually more enlightening to give what you consider good and bad
>> examples as well some examples on the boundary. For example, I rarely
>> want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>>
>> Where in your spectrum of clarity vs. brevity does this sort of use
>> come?
>
> I'd say it's on the lowest end of the spectrum. As soon as people start
> decorating their "auto" with things like "const", "*" or "&" it
> _always_ is. Either the type is self-explanatory or irrelevant, in
> which case plain "auto" will do, or it isn't, in which case "auto" is
> conceptually wrong. Decorating "auto" like that is just a pathetic
> attempt at hiding this simple fact.
If I read you correctly, you think that adding const means the auto is
>> >> Yes but it is tedious. Some types are *LONG*, especially what
>> >> templates can return.
>> >
>> > So what? I very much oppose the brevity-over-clarity style of
>> > programming.
>>
>> As usual, such rules oversimplify the issues. Sometime clarity can
>> actually come from brevity.
>>
>> It's usually more enlightening to give what you consider good and bad
>> examples as well some examples on the boundary. For example, I rarely
>> want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>>
>> Where in your spectrum of clarity vs. brevity does this sort of use
>> come?
>
> I'd say it's on the lowest end of the spectrum. As soon as people start
> decorating their "auto" with things like "const", "*" or "&" it
> _always_ is. Either the type is self-explanatory or irrelevant, in
> which case plain "auto" will do, or it isn't, in which case "auto" is
> conceptually wrong. Decorating "auto" like that is just a pathetic
> attempt at hiding this simple fact.
almost always wrong. Is that your position?
--
Ben.
Tim Rentsch
Dec 9, 2022, 4:05:29 PM12/9/22
to
Juha Nieminen <nos...@thanks.invalid> writes:
> Tiib <oot...@hot.ee> wrote:
>
>> Yes but it is tedious. Some types are *LONG*, especially what templates
>> can return.
>
> So what? I very much oppose the brevity-over-clarity style of
> programming.
There is a tacit assumption in that statement that longer is
> Tiib <oot...@hot.ee> wrote:
>
>> Yes but it is tedious. Some types are *LONG*, especially what templates
>> can return.
>
> So what? I very much oppose the brevity-over-clarity style of
> programming.
always easier to read or more readily comprehended. The
assumption is wrong. Good writers appreciate the difference
between lengthy phrasing and concise phrasing, using each as
appropriate, and varying wording choices between the two, to make
their writing more effective. That advice applies to programming
as much as it does to writing prose.
Tim Rentsch
Dec 9, 2022, 4:07:48 PM12/9/22
to
Andreas Dehmel <blackhole....@spamgourmet.com> writes:
> On Fri, 09 Dec 2022 17:44:27 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>>> [...] I very much oppose the brevity-over-clarity style of
> On Fri, 09 Dec 2022 17:44:27 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>>> programming.
>>
>> As usual, such rules oversimplify the issues. Sometime clarity can
>> actually come from brevity.
>>
>> It's usually more enlightening to give what you consider good and
>> bad examples as well some examples on the boundary. For example, I
>> rarely want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>>
>> Where in your spectrum of clarity vs. brevity does this sort of use
>> come?
>
> I'd say it's on the lowest end of the spectrum. As soon as people start
> decorating their "auto" with things like "const", "*" or "&" it
> _always_ is. Either the type is self-explanatory or irrelevant, in
> which case plain "auto" will do, or it isn't, in which case "auto" is
> conceptually wrong. Decorating "auto" like that is just a pathetic
> attempt at hiding this simple fact.
The assertion that "auto" is conceptually wrong is an opinion,
>>
>> As usual, such rules oversimplify the issues. Sometime clarity can
>> actually come from brevity.
>>
>> It's usually more enlightening to give what you consider good and
>> bad examples as well some examples on the boundary. For example, I
>> rarely want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>>
>> Where in your spectrum of clarity vs. brevity does this sort of use
>> come?
>
> I'd say it's on the lowest end of the spectrum. As soon as people start
> decorating their "auto" with things like "const", "*" or "&" it
> _always_ is. Either the type is self-explanatory or irrelevant, in
> which case plain "auto" will do, or it isn't, in which case "auto" is
> conceptually wrong. Decorating "auto" like that is just a pathetic
> attempt at hiding this simple fact.
not a fact.
Lynn McGuire
Dec 9, 2022, 4:26:06 PM12/9/22
to
Lynn
Andreas Dehmel
Dec 10, 2022, 8:51:36 AM12/10/22
to
On Fri, 09 Dec 2022 20:47:33 +0000
Like I wrote, my position is that adding _any_of_ "const", "*" or "&"
to auto is doing it wrong. It's just trying to hide the fact that you
actually want a specific type but are too lazy to write it down.
And as a general aside, not just relating to "auto", in a language like
C++ where you usually have a long maintenance window, the pains of the
author are insignificant compared to the pains of the maintainer(s).
Andreas
to auto is doing it wrong. It's just trying to hide the fact that you
actually want a specific type but are too lazy to write it down.
And as a general aside, not just relating to "auto", in a language like
C++ where you usually have a long maintenance window, the pains of the
author are insignificant compared to the pains of the maintainer(s).
Andreas
Christian Gollwitzer
Dec 10, 2022, 10:29:59 AM12/10/22
to
Am 08.12.22 um 13:31 schrieb Juha Nieminen:
s case? Have you used dynamic languages like e.g. Python? THere the line
would read:
foobar = someFunction(a, b);
This has never be a big problem when writing Python code. "someFunction"
is a bad description of the return value, that is the problem here. You
wouldn't have the same difficulty to read:
auto x = concat("abc", "123");
or
auto d = sqrt(x**2 + y**2);
Christian
> The problem in using 'auto' everywhere, from the perspective of someone
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b);
>
> it's a complete mystery what that return type is, and thus the reader
> (ie. me) has no idea what it actually is, what it does, and how it's
> used.
My question to you: why do you need to know the type of foobar in thie -
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b);
>
> it's a complete mystery what that return type is, and thus the reader
> (ie. me) has no idea what it actually is, what it does, and how it's
> used.
s case? Have you used dynamic languages like e.g. Python? THere the line
would read:
foobar = someFunction(a, b);
This has never be a big problem when writing Python code. "someFunction"
is a bad description of the return value, that is the problem here. You
wouldn't have the same difficulty to read:
auto x = concat("abc", "123");
or
auto d = sqrt(x**2 + y**2);
Christian
Ben Bacarisse
Dec 10, 2022, 4:53:07 PM12/10/22
to
(you and I) examining it? In my experience, investigating that sort of
opinion, expressed in that style, is rarely fruitful.
--
Ben.
Alf P. Steinbach
Dec 10, 2022, 6:29:45 PM12/10/22
to
class Holder
{
using Variant = variant<
// possible types here
>;
Variant m_variant;
public:
template< class Type >
Holder( in_<Type> e ): m_variant( e ) {}
template< class Type >
auto holds() const
-> bool
{
// TODO: optimize via compile time decisions (type lists).
const auto is_specified_type = []( const auto& e ) -> bool
{
return are_derived_and_base_< Unref_<decltype( e )>,
Type >;
};
return visit( is_specified_type, m_variant );
}
daniel...@gmail.com
Dec 10, 2022, 6:40:05 PM12/10/22
to
On Saturday, December 10, 2022 at 10:29:59 AM UTC-5, Christian Gollwitzer wrote:
> Am 08.12.22 um 13:31 schrieb Juha Nieminen:
> >
> Am 08.12.22 um 13:31 schrieb Juha Nieminen:
> >
> > auto foobar = someFunction(a, b);
> >
> >
> why do you need to know the type of foobar in thie -
> s case?
Minimally, you need to know whether someFunction returns a proxy, if it does,
> s case?
you don't want to use auto. Functions returning proxies aren't that rare in
C++, matrix libraries such as Eigen use them extensively, and there's
even one in the standard library.
>
> This has never be a big problem when writing Python code
But Python is a more coherent language than C++.
> This has never be a big problem when writing Python code
Daniel
Andreas Dehmel
Dec 11, 2022, 8:37:42 AM12/11/22
to
auto function(...) -> bool
can only be a bad joke and is_specified_type() is basically a bog
standard template function that thinks all the cool kids are using auto.
Andreas
David Brown
Dec 11, 2022, 10:43:15 AM12/11/22
to
the actual type are not vital to the working of the code - but it /is/
important that the variable is "const" and a reference, giving efficient
read-only access.
It is emphasising and being explicit about the important aspects while
neatly omitting unimportant (for the code in question) details.
Chris M. Thomasson
Dec 11, 2022, 5:31:36 PM12/11/22
to
On 12/8/2022 4:31 AM, Juha Nieminen wrote:
> During the last few years I have had to read an inordinate amount of
> code written by other people. It has really given me a big insight on
> what makes code more and less readable and understandable. For example,
> I could write an entire book on naming conventions alone, and how they
> can make the code so much more readable, or make it almost inscrutable.
>
> But another thing I have really learned to hate is the overuse of the
> 'auto' keyword. I have always opposed its needless overuse, but this
> couple of years of reading other people's code has really confirmed
> and cemented my previous opinion on it.
>
> Some C++ programmers do not use 'auto' merely to save some typing,
> as some kind of convenience feature. They go their way to use it
> pretty much everywhere they can, even when it doesn't actually save
> any typing or make anything more convenient. They use it like it were
> the generic variable declaration keyword in many other languages
> (quite typically "var").
>
> The problem in using 'auto' everywhere, from the perspective of someone
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b)
[...]
> During the last few years I have had to read an inordinate amount of
> code written by other people. It has really given me a big insight on
> what makes code more and less readable and understandable. For example,
> I could write an entire book on naming conventions alone, and how they
> can make the code so much more readable, or make it almost inscrutable.
>
> But another thing I have really learned to hate is the overuse of the
> 'auto' keyword. I have always opposed its needless overuse, but this
> couple of years of reading other people's code has really confirmed
> and cemented my previous opinion on it.
>
> Some C++ programmers do not use 'auto' merely to save some typing,
> as some kind of convenience feature. They go their way to use it
> pretty much everywhere they can, even when it doesn't actually save
> any typing or make anything more convenient. They use it like it were
> the generic variable declaration keyword in many other languages
> (quite typically "var").
>
> The problem in using 'auto' everywhere, from the perspective of someone
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b)
Indeed. I find myself instantly looking for the declaration of
someFunction so I can make a note... foobar = a pointer to foobaz.
Juha Nieminen
Dec 12, 2022, 1:59:58 AM12/12/22
to
Michael S <already...@yahoo.com> wrote:
> You are maturing.
> Few more years and you'll start to agree with your famous former compatriot.
>
> "C++ is a horrible language. It's made more horrible by the fact that a lot
> of substandard programmers use it, to the point where it's much much
> easier to generate total and utter crap with it. Quite frankly, even if
> the choice of C were to do *nothing* but keep the C++ programmers out,
> that in itself would be a huge reason to use C.".
>
> https://lwn.net/Articles/249460/
I hope I never become that retarded.
> You are maturing.
> Few more years and you'll start to agree with your famous former compatriot.
>
> "C++ is a horrible language. It's made more horrible by the fact that a lot
> of substandard programmers use it, to the point where it's much much
> easier to generate total and utter crap with it. Quite frankly, even if
> the choice of C were to do *nothing* but keep the C++ programmers out,
> that in itself would be a huge reason to use C.".
>
> https://lwn.net/Articles/249460/
Juha Nieminen
Dec 12, 2022, 2:04:42 AM12/12/22
to
Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>
>> Tiib <oot...@hot.ee> wrote:
>>
>>> Yes but it is tedious. Some types are *LONG*, especially what templates
>>> can return.
>>
>> So what? I very much oppose the brevity-over-clarity style of
>> programming.
>
> There is a tacit assumption in that statement that longer is
> always easier to read or more readily comprehended.
No, there isn't. Overly short being hard to read does not mean that
> Juha Nieminen <nos...@thanks.invalid> writes:
>
>> Tiib <oot...@hot.ee> wrote:
>>
>>> Yes but it is tedious. Some types are *LONG*, especially what templates
>>> can return.
>>
>> So what? I very much oppose the brevity-over-clarity style of
>> programming.
>
> There is a tacit assumption in that statement that longer is
> always easier to read or more readily comprehended.
overly long is easy to read. Overly long can perfectly well *also*
be hard to read.
You have to reach the optimal middle: Not too short, not too long.
The name must convey clearly its meaning. If you make it too
compressed or too sparse, it becomes harder to discern this meaning.
The problem I see in 99.99% of programming is that people tend to
always go with the overly short, usually for no reason whatsoever.
Juha Nieminen
Dec 12, 2022, 2:10:33 AM12/12/22
to
Christian Gollwitzer <auri...@gmx.de> wrote:
> Am 08.12.22 um 13:31 schrieb Juha Nieminen:
>> The problem in using 'auto' everywhere, from the perspective of someone
>> who is reading the code, is that it hides the type in question. When
>> you see something like:
>>
>> auto foobar = someFunction(a, b);
>>
>> it's a complete mystery what that return type is, and thus the reader
>> (ie. me) has no idea what it actually is, what it does, and how it's
>> used.
>
> My question to you: why do you need to know the type of foobar in thie -
> s case?
Because it helps me understand what that is doing, and what subsequent
> Am 08.12.22 um 13:31 schrieb Juha Nieminen:
>> The problem in using 'auto' everywhere, from the perspective of someone
>> who is reading the code, is that it hides the type in question. When
>> you see something like:
>>
>> auto foobar = someFunction(a, b);
>>
>> it's a complete mystery what that return type is, and thus the reader
>> (ie. me) has no idea what it actually is, what it does, and how it's
>> used.
>
> My question to you: why do you need to know the type of foobar in thie -
> s case?
lines are doing. There's quite a difference whehter that return type is
an int, a const char*, or a std::string, and if the return type is
specified right there, it immediately helps me understand what's
happening. The 'auto' tells me *absolutely nothing* about what's
happening there.
When 'auto' is used, the subsequent lines don't necessarily help me
know what that type is. Is it an 'int'? An 'unsigned int'? A 'double'?
A 'float'? Subsequent lines don't necessarily help me see which one
of those it is, or perhaps some other similar type. This information
is hidden from this piece of code, for no good reason.
> This has never be a big problem when writing Python code. "someFunction"
> is a bad description of the return value, that is the problem here. You
> wouldn't have the same difficulty to read:
>
> auto x = concat("abc", "123");
That's quite a big difference.
Juha Nieminen
Dec 12, 2022, 2:14:35 AM12/12/22
to
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> It's usually more enlightening to give what you consider good and bad
> examples as well some examples on the boundary. For example, I rarely
> want to know more about the type when I see
>
> for (const auto &elem : <something>) ...
I find it quite strange that you aren't interested in what that element
> It's usually more enlightening to give what you consider good and bad
> examples as well some examples on the boundary. For example, I rarely
> want to know more about the type when I see
>
> for (const auto &elem : <something>) ...
type is. When you know nothing about the type, you have no way of
knowing what to expect in the subsequent lines of code. Looking at
that line alone it may be completely unclear what it's actually doing
(depending on what that <something> is).
Compare it to, say:
for (const std::string& elem: <something>)
Aha! Now we know a lot more about what <something> is, and what to
expect in subsequent lines of code. Just that one little change is
giving us a lot more information and clarity about what's happening here.
David Brown
Dec 12, 2022, 2:55:06 AM12/12/22
to
On 12/12/2022 08:14, Juha Nieminen wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> It's usually more enlightening to give what you consider good and bad
>> examples as well some examples on the boundary. For example, I rarely
>> want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>
> I find it quite strange that you aren't interested in what that element
> type is. When you know nothing about the type, you have no way of
> knowing what to expect in the subsequent lines of code. Looking at
> that line alone it may be completely unclear what it's actually doing
> (depending on what that <something> is).
>
I find it strange that you expect to understand code line by line,
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> It's usually more enlightening to give what you consider good and bad
>> examples as well some examples on the boundary. For example, I rarely
>> want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>
> I find it quite strange that you aren't interested in what that element
> type is. When you know nothing about the type, you have no way of
> knowing what to expect in the subsequent lines of code. Looking at
> that line alone it may be completely unclear what it's actually doing
> (depending on what that <something> is).
>
rather than looking at the context. This is especially true given that
full types in C++ can regularly take more than a single line to write out.
When I use "auto", it is because the details of the type don't matter
significantly, or they are clear from the context, or that they are too
convoluted to be convenient to write out manually, or that the code is
intended to be somewhat general. I think a combination of the first two
is the most common.
> Compare it to, say:
>
> for (const std::string& elem: <something>)
>
> Aha! Now we know a lot more about what <something> is, and what to
> expect in subsequent lines of code. Just that one little change is
> giving us a lot more information and clarity about what's happening here.
void foo(std::vector<std::string> somethings) {
for (const auto &elem : somethings) ...
Why bother re-writing std::string inside the for loop? It doesn't make
the code any clearer or safer - it is unnecessary repetition.
(Programmers should have KISS tattooed on the inside of one eyelid, and
DRY tattooed on the inside of the other.) The types are clear as day.
And if they are changed - maybe "foo" gets changed to wide strings - the
rest of the code is unchanged with "auto". But if you have manually
written out the full type, you now have to remember to make changes in
more places or you've got highly unexpected conversions lying around.
/Overuse/ of auto is, of course, a bad thing - overuse of anything is
bad, by the definition of the word. And sometimes there are better
alternatives, such as "using" to make a local typename that is more
convenient, or concepts as "constrained auto". But very often, "auto"
is simple, convenient, improves clarity and reduces the risk of errors.
In such cases it is a very good thing.
Alf P. Steinbach
Dec 12, 2022, 3:35:50 AM12/12/22
to
- Alf
David Brown
Dec 12, 2022, 3:49:40 AM12/12/22
to
than "auto" when the exact type matters and it is not clear from the
context. But often the type details /don't/ matter, or they /are/ clear
from the context - and then "auto" is fine.
It's not really any different from all sorts of other aspects of
programming - you always have a balance between being explicit and
wordy, or being implicit and simpler.
Juha Nieminen
Dec 12, 2022, 6:32:13 AM12/12/22
to
David Brown <david...@hesbynett.no> wrote:
> I find it strange that you expect to understand code line by line,
> rather than looking at the context.
I don't find it strange at all. The clearer the code is, the better.
> I find it strange that you expect to understand code line by line,
> rather than looking at the context.
If you can understand what a line of code is doing without having
to look at the surrounding code, all the better. (Sometimes this is
just not possible, of course, but if with a simple change you can
make it so, why not?)
> This is especially true given that
> full types in C++ can regularly take more than a single line to write out.
My disdain for overt brevity has not appeared out of the blue. It's the
consequence of years of having to have read tens of thousands of lines
of code written by other people.
Length does not matter. Clarity does.
> When I use "auto", it is because the details of the type don't matter
> significantly, or they are clear from the context, or that they are too
> convoluted to be convenient to write out manually, or that the code is
> intended to be somewhat general. I think a combination of the first two
> is the most common.
code, then *perhaps* it's acceptable. However, my point is that 'auto'
is being *overused* a lot. In other words, in many situations where
it's *not* clear at all what it's expanding to (often requiring going
to an entirely different file to see what it actually is. IDEs help
with this, but IMO code should be readable without the help of any
IDEs.)
>> Compare it to, say:
>>
>> for (const std::string& elem: <something>)
>>
>> Aha! Now we know a lot more about what <something> is, and what to
>> expect in subsequent lines of code. Just that one little change is
>> giving us a lot more information and clarity about what's happening here.
>
> Compare it to :
>
> void foo(std::vector<std::string> somethings) {
>
> for (const auto &elem : somethings) ...
dozen lines before that loop. Will you then change that 'auto' to the
actual type? Unlikely.
> Why bother re-writing std::string inside the for loop? It doesn't make
> the code any clearer or safer - it is unnecessary repetition.
You write the same words in your English prose again and again and again.
You don't see that as a problem. Why do you find it a problem in code?
> (Programmers should have KISS tattooed on the inside of one eyelid, and
> DRY tattooed on the inside of the other.)
nobody will understand it.
Keep your code smart, not stupid.
> And if they are changed - maybe "foo" gets changed to wide strings - the
> rest of the code is unchanged with "auto". But if you have manually
> written out the full type, you now have to remember to make changes in
> more places or you've got highly unexpected conversions lying around.
code, subsequent 'auto' keywords may hide your mistake, while explicit
types could have caught it immediately.
Juha Nieminen
Dec 12, 2022, 6:35:20 AM12/12/22
to
David Brown <david...@hesbynett.no> wrote:
> I don't think
> I don't think