Monday, December 19, 2022

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

Juha Nieminen <nospam@thanks.invalid>: Dec 19 07:32AM

> information. So there's a lot of "find", "size", "empty" and so on.
> If I have problems coming up with a name like that, the first thing I
> do is check if I should review my set of types.
 
Sure, names should not contain *redundant* information. Ie. names should
not contain English words that do not add information to the name that's
already conveyed by the other words in the name (ie. there's no need to
state the same thing twice, even if you use two different words to
express the thing). Also words that may not repeat what other words in
the name are already saying, but which do not add any information to
the name can be avoided.
 
However, variable/function/type names should still use as many words
as necessary to clearly express and disambiguate what it's doing or
what its role is.
 
As an example, "convert()" doesn't contain enough information to tell
me what that function is doing. Convert what? Into what? Such a function
name should tell directly what it's converting, and into what, so that
it becomes clear from that name alone.
 
If you require a more generic name like that for the purposes of
overloading (eg. because that overloaded function is being used in
templated code), IMO it's *still* preferable to create uniquely-named
functions that disambiguate what they are doing, and then make the
overloaded functions call those. And in code that does not need the
overloading the uniquely-named versions should be called.
 
This is because it makes the code easier to read and understand.
 
> To me this isn't a maintenance problem: it's obvious at the call site
> which one I mean. If it's not, then I haven't understood the calling
> code well enough to have a reason to follow the call.
 
You should not be writing code for yourself. You should be writing it
for others. Obviously *you* understand what the code is doing because
you are writing it. You already know the intent, and you are just
implementing that intent. However, a third-party reader doesn't know
the intent of the code beforehand, and thus the direction is reversed:
The third-party reader needs to decipher the intent from the code.
 
And that "third-party reader" may well be you yourself, years later,
long after you have forgotten the details of the code. So in that way
you are also writing it for your (future) self.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 07:35AM


>>With the prefix it becomes a lot clearer where that func() is, and thus
>>the code is much easier to understand.
 
> So why not just use prefixes instead of namespaces?
 
If you want to use prefixes instead of namespaces, go right ahead.
 
You'll be inducing the users of your library to write better clearer
code, so there's a positive.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 07:46AM

> I use "using" locally in functions when it makes code simpler and
> clearer, because it makes names shorter and has less clutter.
 
And there we go again with the brevity argument. Again, and again, and
again, and again. Ad infinitum.
 
Sorter code is not necessarily clearer code. In fact, quite often it's
the opposite. Where does this strange concept come from, that shorter
is clearer? I don't see you using abbreviations in your English prose.
Why not? Because if you abbreviated every single word in your text,
it would become near illegible. That's why. You use full English words
because your text becomes more legible that way.
 
Why is it different in program code?
 
Well, it isn't. Also program code becomes more legible when it's actually
stating, using full English words, what it's doing, instead of being full
of cryptic abbreviations and acronyms.
 
The brevity-over-clarity style of programming will probably be a curse
in programming for as long as humanity will exist and keep writing
programs.
 
> It also
> makes it clearer that I am "using" a particular imported namespace.
 
Do you know what makes it even clearer? Saying so in the names from that
namespace. The reader doesn't have to guess when it's explicitly stated.
 
I will never understand why so many programmers fight tooth and nail
against this concept.
 
> display;" in that function. It is a /good/ thing to write "clear();" or
> "get_dimensions()" rather than "display::clear();" and
> "display::get_dimensions()".
 
I see absolutely nothing "good" about it. I can only see negatives.
 
How would I know what the 'clear()' is doing, or where it comes from?
Maybe it's clearing the data structures of this class? How would I know?
 
You seem completely unable to position yourself in the shoes of a
third-party reading your code.
 
> People don't like having to write long prefixes when it is obvious from
> the context of the code which library or set of identifiers you are
> using.
 
But that's the problem: It may be obvious *to you*, the person writing
the code. It may be far from obvious to someone else who is reading your
code and doesn't know in advance what it's doing. When you specify the
prefixes you are helping the reader understand what that name is and
where it comes from.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 07:58AM


> and then "UL(foo)(123);" instead of "user_library_foo(123);"
 
> I'm going to go out on a limb and guess that Juha would like that even
> less than a "using namespace" clause!
 
You are correct in that. If I were to be forced at gunpoint to choose
between the two, I would choose 'using namespace'.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 08:16AM


> Its convention. 'i' has been the top level index counter since 1980s BASIC.
> You'll probably find it used as an index var in for() in just about every large
> C and C++ program ever written.
 
We don't live in the 1980's anymore, nor are we writing BASIC.
Bad habits don't become good habits just because they have existed
for a long time.
 
>>named clearly after what it's going to index, compared to if they
>>are just named 'i', 'j' and 'k'.
 
> Clearer for you maybe. For me i, j and k would be perfectly clear.
 
Well, exactly.
 
When you are *writing* the code, *you* know what that 'i' is going
to index when you are writing the for-statement because you have a
clear picture in your mind of what that for-statement is doing.
However, when I am *reading* your code, *I* don't know what that
'i' is going to index because I don't yet know the intent of that
for-loop. Additionally, the 'i' buried deep into the for-loop
body makes it harder to find with a quick visual scan.
 
If, however, you use a name like 'name_index', or 'column_index',
then I know immediately when reading that for-statement what that
variable is going to index and thus what the loop is for.
 
I honestly cannot understand what's so hard to accept in this,
and why it reserves such strong opposition.
 
>>used for, it's much easier to understand than if it's just a
>>short generic name that says nothing.
 
> Speak for yourself.
 
I speak for the person reading the code. Which by this point
I have *a lot* of experience on. These opinions are not based
on random thoughts. They are based on literally *years* of
experience in reading tens of thousands, even hundreds of
thousands of lines of code written by other people. I have
seen countless times the difference it makes when people
name variables and functions clearly or unclearly, or when
they overuse the 'auto' keyword, or when they overload
functions for no good reason.
 
>>> Long winded names are as bad as names that are meaningless.
 
>>That's just a completely asinine assertion.
 
> Go read some Java.
 
I haven't read much Java, but you are actually (and perhaps a bit
ironically) making it sound like typical Java code is actually
easier to read and understand than typical C++ or C code.
 
>>If long-winded names are bad, then why do you use long words when
>>you write English? Why don't you contract every word you use?
 
> I guess you've never used SMS.
 
I don't see you using cryptic abbreviations in your English prose
here...
Juha Nieminen <nospam@thanks.invalid>: Dec 19 08:39AM

> Text where recently introduced (within 3-4 code lines) variable
> with long name participates multiple times feels far from easier
> to read.
 
Are you basing that opinion on code that *you* have written, or are
you basing it on code by other people that you have had to read?
 
Because I am basing my opinion on tons and tons of code that I have
had to read. Clearer variable names (such as loop variable names)
make a world of a difference in understanding the code.
 
When I'm writing code, I sometimes find myself instinctively and
out of old bad habit using eg. loop variable names that are too
short and too cryptic, and I have been trying to unlearn this bad
habit and use clearer names. I myself can then see clearly the
difference that makes when I have to read my own code much later.
 
This is *especially* the case with nested loops. With some very
short single loops you could perhaps get away with using
single-letter index variables. But the longer the loops, and the
more they are nested, the more important it becomes to name the
loop variables clearly.
 
> What you typically write like "foobar" ... to me just "f" is lot better
> as "foobar" anyway means nothing.
 
Then that name is poorly chosen. It's not about length. It's about
clarity. The name should clearly express what the thing is for, or
what it's doing.
 
Why are people so obsessed with length? For the umpteenth time:
Length doesn't matter. Length is irrelevant. It's not about making
names longer or shorter. It's about making them more legible and
easier to understand. Oftentimes that means making them longer,
but that's just an irrelevant side-effect, not the core goal.
 
Names do not become clearer if they are shorter or longer. They
become clearer based on their content. Sometimes clearer does mean
longer, but that's just a side effect.
 
> or "k" is index of current key then names "index_of_current_image"
> and "index_of_current_key" would not help at all. Opposite has been
> evident. Demonstrate how it is not.
 
I always love it when people give counter-examples by adding
completely redundant words to the variable names, just for the
sake of making them longer.
 
"image_index" is a better name than "index_of_current_image" because
it doesn't contain redundant information. (The fact that it's also
shorter is irrelevant. As said, length does not matter.)
 
Use as many (full English) words to express what the thing is for,
but do not add redundant words that add no useful information.
 
I still fail to undrestand how this is so controversial and worthy of
such heavy opposition. We are not writing code for the Obfuscated C
Code Contest here.
 
> It is similar to spoken language where we say "it" or "he"
 
There we go again with the length argument. How many times do I have
to repeat that it's not about the length? A word being shorter or
longer is completely irrelevant. It's not about the length of the word.
It's about clarity and legibility.
 
> in mathematics
 
Mathematics is an extremely poor example because mathematicians are
almost proud about the fact that their scribbles are as compressed
and cryptic as possible.
 
> Also in legal texts we define shorthands for
> not to write same thing over and over again.
 
As with length, also repetition does not matter. Legibility does. If
repeating the same word twenty times makes the code more understanable,
that's all that matters. The repetition itself is irrelevant. We don't
need to save disk space.
 
I could add a kind of corollary to my "use as many words as necessary,
but no more" sentiment: "Repeat the same name in your code as many
times as necessary, but no more."
 
>> word your text would become illegible. Why is code any different?
 
> You are mistaken. Pronouns like it, him, they, there, then are used
> massively in spoken language.
 
They are full words. They are not contractions or acronyms.
 
> We do exactly same what is done in spoken language, mathematics
> or legal texts.
 
Using mathematics and legal text as examples of "legible" and
"understandable" text is just hilarious. Legalese is anything but.
 
As for spoken language, you don't speak using contractions. You
speak using full words.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 08:54AM

> int calculate_average_of_vector_of_ints(std::vector<int>
> vector_of_ints_to_average)
 
As always, you use redundant information to artificially lengthen names.
 
That's arguing in bad faith.
 
> nothing (what information does it give you in "return returnValue;" ?)
> The only conceivable reason to have it is that the function is so long
> the it is unclear what it is returning - and /that/ is the problem to fix.
 
For starters, I gave "returnValue" as a better alternative to "ret".
That "ret" is not giving you any more information than "returnValue",
but it's more cryptic for no good reason. If you were to reject the
use of "returnValue" in favor of "ret" then... well, it's better I
don't continue this sentence.
 
> The same goes for "errorCode". If it is not clear from the code that
> "err" is an error code, /that/ is the problem - not the name of the
> variable.
 
There's zero reason to make the name more cryptic than it has to be.
 
You are now just arguing for the sake of arguing, and it makes no sense.
I honestly cannot understand why this is so controversial and deserving
of such strong opposition. It feels like I have been suggesting to use
profanity, swearwords and politically offensive terminology in variable
and function names.
 
> Or are you happy that /sometimes/ it's okay to write short code
> whose meaning is clear to everyone reading it, and you don't have to
> write out /everything/ in the longest, most explicit manner?
 
There we go again with the length argument.
 
How many times do I have to repeat this? IT'S NOT ABOUT LENGTH!
It's about legibility and understandability. Sometimes increased
legibility makes names longer, but that's just an irrelevant side
effect. The length itself is not the primary goal.
 
How hard is that to understand, honestly?
Juha Nieminen <nospam@thanks.invalid>: Dec 19 08:58AM

> did a reasonable job, but the result is inconsistent and surprising in
> some ways. I would much preferred inefficiency and consistency, and a
> separate type ("bit_vector") for compactness.
 
Yeah, in retrospect it may have been better if they had kept std::vector
with a single implementation without a separate specialization for bool,
and instead created an entirely different class for handling a dynamic
array of bits.
 
Well, at least std::vector<bool> doesn't come with 87.5% wasted space,
which is a positive.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 09:06AM

> You don't know. You'll have to look at their declarations to see. But
> maybe it's enough to know they are types whose product can be implicitly
> converted to an "int".
 
While it's not perfect, at least it's better than "auto x = a * b;"
because at least you have *some* information, which is better than none.
 
Incidentally, naming those variables more clearly could also help
understanding better that line of code. For example, if the variables
were named "row_index" and "table_width", suddenly that line becomes
extraordinarily clearer than if they are just "a" and "b".
 
> If I write "int x = foo(y);", what are all the types involved? You
> don't know.
 
Here, too, naming the function and the variables more clearly may help
understanding better what that line is doing and what the variables and
their types are.
 
Which is my entire point in this thread.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 09:15AM

> People's brains must simply be wired differently. I prefer short names
> (I already like "tpr" and memorized its meaning) and yet I /do/ care
> deeply about maintainability.
 
You know what the acronym stands for because I told you. It was not told
in the code I'm talking about. I had to figure it out myself, once again
because to the programmer it was clear but not to the reader. This is
completely useless wasting of time of the reader for no benefit.
 
In addition, when the code is full of cryptic acronyms, it becomes
harder to read because it's just a big bunch of random-looking characters
instead of clear English words. If the variable is named "test_point_right"
I can see all of its uses in the code quite clearly with a quick visual
scan. If it's named "tpr" I cannot, especially when it's mixed with other
acronyms like "tpl" and similar, plus a bunch of C++ syntax, all highly
compressed into a small space full of letters and non-ascii characters.
 
There's literally no reason to prefer "tpr" over "test_point_right".
There are no benefits of any kind, there are only drawbacks.
Muttley@dastardlyhq.com: Dec 19 09:40AM

On Mon, 19 Dec 2022 08:16:48 -0000 (UTC)
 
>We don't live in the 1980's anymore, nor are we writing BASIC.
>Bad habits don't become good habits just because they have existed
>for a long time.
 
If habits hang around for a long time its usually because they're good, not
bad.
 
>If, however, you use a name like 'name_index', or 'column_index',
>then I know immediately when reading that for-statement what that
>variable is going to index and thus what the loop is for.
 
Because it becomes noise amongst all the other variable names. We're not
writing prose, we're writing code. Code should be clear and to the point.
 
>I honestly cannot understand what's so hard to accept in this,
>and why it reserves such strong opposition.
 
Stop pretending your opinions are facts. Its personal preference, nothing more.
 
>on random thoughts. They are based on literally *years* of
>experience in reading tens of thousands, even hundreds of
>thousands of lines of code written by other people. I have
 
You think you're the only person on this group who's had to work on other
peoples code?
 
>they overuse the 'auto' keyword, or when they overload
>functions for no good reason.
 
I'll agree with you on those.
 
>I haven't read much Java, but you are actually (and perhaps a bit
>ironically) making it sound like typical Java code is actually
>easier to read and understand than typical C++ or C code.
 
No, it isn't. Because code should be scannable by quickly by eye. If the
variable and function names are so long you have to read it like prose then
you quickly lose track of whats going on because your short term memory can't
hold it all for long enough.
 
 
>> I guess you've never used SMS.
 
>I don't see you using cryptic abbreviations in your English prose
>here...
 
What, like SMS? :)
Juha Nieminen <nospam@thanks.invalid>: Dec 19 12:10PM

> If habits hang around for a long time its usually because they're good, not
> bad.
 
You can't be serious.
 
>>I honestly cannot understand what's so hard to accept in this,
>>and why it reserves such strong opposition.
 
> Stop pretending your opinions are facts. Its personal preference, nothing more.
 
You can argue against it all you want, you can write ten miles of text
repeating your objections over and over and over, but you cannot change
what I see with my own eyes.
 
I have had to read inordinate amounts of code written by other people,
having to fully understand what the code is doing, for several years
now. You cannot make what I have seen clearer and easier to understand
no matter how much you argue that it is. You cannot make osbcure
cryptic obfuscated acronyms clearer and easier to understand than
fully written-out words because I can see clearly with my own eyes
which one is easier to understand and which makes the code easier
to read. Code that I need to actually understand what it's doing.
 
I cannot understand why you insist so vehemently in defending writing
cryptic obfsucated code. It's relatively clear that you are arguing
just for the sake of arguing. No matter what I say, you will argue
against it, just for the sake of arguing against it.
 
Get into your thick skull that just because *you* can understand
your own code which you are writing at the moment, that doesn't
mean that *somebody else* is going to understand it equally
easily. *You* may know what the cryptic acronym is representing.
*You* may know what the 'i' will be indexing. *You* may know
what the 'auto' is standing for. That's because *you* are writing
the code so you know what you want to express. Someone else,
however, cannot read your mind. Someone else reading the code has
to decipher what you were thinking from that code. If you refuse
to express clearly what you are trying to express, that makes it
so much harder for that person to understand it.
 
> You think you're the only person on this group who's had to work on other
> peoples code?
 
Deducing from these response, it appears to be so.
 
If people had *actually* had to decipher hundreds of thousands of lines
of obscure cryptic code they may perhaps be more agreeable on the
importance of actually saying what you want to express in the code
rather than actively trying to hide it behind cryptic abbreviations
and 'auto' keywords.
 
I don't even understand what there is to oppose in that idea.
I especially am unable to understand how someone could suggest that
the cryptic acronyms and abbreviations are easier to read and
understand than the fully written-out English words.
 
Quite clearly you haven't had to decipher other people's code if
you think that obfuscation makes the code easier to understand.
 
> variable and function names are so long you have to read it like prose then
> you quickly lose track of whats going on because your short term memory can't
> hold it all for long enough.
 
You are still making it sound like typical Java code is more readable
than typical C or C++ code.
 
> What, like SMS? :)
 
One of my exceptions to the rule is "unless it's a universally used term
or acronym which meaning is very clear".
 
That does not include your own acronyms that you made up for your
particular piece of code, because those are not universally used.
Paavo Helde <eesnimi@osa.pri.ee>: Dec 19 02:55PM +0200

19.12.2022 09:46 Juha Nieminen kirjutas:
> again, and again. Ad infinitum.
 
> Sorter code is not necessarily clearer code. In fact, quite often it's
> the opposite.
 
And longer code is not necessarily clearer code. Hereby I present a
snippet of actual code from a former coworker who strongly believed in
long self-explanatory names. He also believed in 76-char line limit.
These goals are a bit contradictory, I guess that's why there appear
copies of variables with shorter names inside the function, and maybe
this also explains occasional one-letter function names like 'q'.
 
The function Validate_ObjectsSetCardinalityEquality_type1_helper1() is
called once from the rest of the program, from a function with the name
- you guessed it - Validate_ObjectsSetCardinalityEquality_type1() and
which looks mostly the same.
 
He was also very keen on program speed and optimizations, I guess that's
why the functions are marked 'inline'. Never mind pass of string
arguments by value, or using these two full functions for making a
single integer comparison in the first place.
 
inline std::string q(const std::string& s) {
return ("\"" + s + "\"");
}
 
inline void Validate_ObjectsSetCardinalityEquality_type1_helper1(
int number_of_objects_in_the_1_comparable,
int number_of_objects_in_the_2_comparable,
std::string name_of_the_1_comparable,
std::string name_of_the_2_comparable,
std::string type_name_of_the_1_comparable,
std::string type_name_of_the_2_comparable
) {
int n_1 = number_of_objects_in_the_1_comparable;
int n_2 = number_of_objects_in_the_2_comparable;
std::string AssertionFailureMessage = "";
if (n_1 != n_2) {
std::string name1 = name_of_the_1_comparable;
std::string name2 = name_of_the_2_comparable;
std::string name2a = "";
std::string t_name1 = type_name_of_the_1_comparable;
std::string t_name2 = type_name_of_the_2_comparable;
name2a = name2;
if (!type_name_of_the_1_comparable.empty()) {
name1 = ", " + q(name1) + ", ";
} //if
else {
name1 = " " + q(name1) + " ";
} //else
if (!type_name_of_the_2_comparable.empty()) {
name2 = ", " + q(name2) + ", ";
name2a = ", " + q(name2) + ", ";
} //if
else {
name2 = " " + q(name2) + " ";
name2a = " " + q(name2) + ", ";
} //else
AssertionFailureMessage = "\n\n"
"The number of objects at " +
t_name1 + name1 + "(==" + str(n_1) + ")\n"
"did not match with the number "
"of objects at " +
t_name2 + name2 + "(==" + str(n_2) + ").\n"
"It is assumed that both, the " +
t_name1 + name1 + "\n"
"and the " +
t_name2 + name2a + " "
"have exactly the same\n"
"number of objects."
"\n\n";
throw AdrasteaAssertionFailure(AssertionFailureMessage);
} // if
} // Validate_ObjectsSetCardinalityEquality_type1_helper1()
;
David Brown <david.brown@hesbynett.no>: Dec 19 02:05PM +0100

On 19/12/2022 08:46, Juha Nieminen wrote:
>> clearer, because it makes names shorter and has less clutter.
 
> And there we go again with the brevity argument. Again, and again, and
> again, and again. Ad infinitum.
 
I can't help it if it is true that shorter names are easier to read than
longer names, as long as they are unambiguous in the context.
 
Shorter names are easier to read, and faster to interpret. They have
lower cognitive load. It uses less brainpower to read "i" and "x" than
"loop_index" and "current_value". Less effort means fewer mistakes, and
more of your brain's "bandwidth" is available for more important aspects
of the task of understanding the code.
 
So no matter how often /you/ repeat your unfounded assertions than short
names and short code is inherently bad, you will still be wrong.
 
 
 
> Sorter code is not necessarily clearer code.
 
For a person that is so concerned about reading and understanding code,
you are doing a rather poor job of reading and understanding people's
posts in this thread.
 
/No one/ has made any suggestion that "shorter code is /necessarily/
clearer". We have said that when the purpose of the identifier is
unambiguous, /then/ a shorter identifier is clearer. Please tell me you
understand the difference.
 
 
> The brevity-over-clarity style of programming will probably be a curse
> in programming for as long as humanity will exist and keep writing
> programs.
 
/No one/ is promoting "bevity-over-clarity". We are arguing for
"clarity-over-length".
 
Yes, there are bad programmers out there, coming up with all sorts of
new ways to annoy the people that have to look at their code. A few of
them will think shorter names are always clearer - far more will use
short names without regard to clarity. Others will use overly long
names in a mistaken believe that long identifiers always make code
easier to understand, just as some believe that copious comments are
helpful by sheer quantity, rather than quality.
 
 
>> makes it clearer that I am "using" a particular imported namespace.
 
> Do you know what makes it even clearer? Saying so in the names from that
> namespace. The reader doesn't have to guess when it's explicitly stated.
 
If the user is guessing, you're doing things wrong.
 
> I will never understand why so many programmers fight tooth and nail
> against this concept.
 
 
Then I guess you'll never understand how almost all programmers work.
And I'll never understand why you are obsessed with the illusion - as it
/is/ an illusion - that code can be understood line by line, or that it
is advantageous to do so.
 
>> "display::get_dimensions()".
 
> I see absolutely nothing "good" about it. I can only see negatives.
 
> How would I know what the 'clear()' is doing, or where it comes from?
 
You'd know because it is obvious from the code if you dare to look at it.
 
> Maybe it's clearing the data structures of this class? How would I know?
 
> You seem completely unable to position yourself in the shoes of a
> third-party reading your code.
 
Sorry, but again you are /completely/ wrong.
 
Take a book off your shelf. Open it at random. Pick a sentence
half-way down the page. Do you really expect to be able to understand
everything that is going on in that sentence from the sentence alone?
Of course you don't. Why would you expect to do so in code?
 
I expect code to be clear and understandable - in /appropriately/ sized
units. I expect people to understand a little by reading just one line.
I expect them to understand far more by reading a function. And yet
more by looking at the class as a whole. And so on, up the hierarchy of
classes, files, namespaces, libraries, etc.
 
The last thing I would want to impose on someone reading my code is
pointless repetition of information that is already clear - that just
makes everything harder to read and comprehend.
 
I really do not understand where your attitude comes from. It is
contradictory to everything done in programming since the invention of
the subroutine! You take a bit of code that is long enough to have
meaning, and long enough to be an effort to understand at a glance, and
you isolate it and give it a name that is short and easy to absorb in an
instant. Then you use the short name instead of the long code. That is
how we have named functions, named classes, named libraries, and
everything else with names. And it is how we handle identifiers - long
enough to be clear, but short enough to be readable and quickly
understood within their context.
 
Have you ever done any mathematics? Which do you think is clearer: "The
height on the vertical axis is equal to the distance along the
horizontal axis squared plus four times the distance along the
horizontal access minus three", or "y = x² + 4x - 3" ?
 
 
> code and doesn't know in advance what it's doing. When you specify the
> prefixes you are helping the reader understand what that name is and
> where it comes from.
 
I don't care about the person writing the code. I care about the person
/reading/ the code. I care that they can understand what the code does
- that they can understand the /important/ aspects of the code. I don't
want them to have to wade through endless repetitions of nested
namespaces, or long sentences where a short identifier does the job
better. I want them to be able to see what is going on as easily and as
error-free as possible.
 
No one is suggesting you have 50 line functions where the only variables
are "int tmp1,tmp2,tmp3;" at the top of the function and then re-used
for a dozen purposes - we all know there are people who write such code,
and we all know it is incomprehensible and unmaintainable.
 
Write short, clear functions and the variables can be short and clear.
/Good/ names and identifiers are a key art in programming. But length
or the use of whole words and phrases instead of short names and
/obvious/ abbreviations is not a substitute for good naming. I'd
certainly rather see "tmp" than "temporary_value".
"Öö Tiib" <ootiib@hot.ee>: Dec 19 05:27AM -0800

On Monday, 19 December 2022 at 10:39:18 UTC+2, Juha Nieminen wrote:
> > to read.
> Are you basing that opinion on code that *you* have written, or are
> you basing it on code by other people that you have had to read?
 
I am writing all less of code than I would like to. Need to give advice,
need to read various ideas, need to review, need to attend meetings.
My improvement proposals have also been lately more about removing
something redundant than about adding new complications. But we
should not contest who has read more hundreds of thousands lines
of code as with decades these add up inevitably.
> single-letter index variables. But the longer the loops, and the
> more they are nested, the more important it becomes to name the
> loop variables clearly.
 
Such nested loops themselves have smell of brute force solution
and non-scalable time-complexity. When I see those then I feel obliged
to think deeper as O(I*J*K) is typically THE performance bottle-neck.
When it is unavoidable then order of nesting may matter to cache
friendliness. I actually lack example where verbosity makes it easier
to think about those things.
> names longer or shorter. It's about making them more legible and
> easier to understand. Oftentimes that means making them longer,
> but that's just an irrelevant side-effect, not the core goal.
 
It does not indeed matter at all when I type. IDEs just propose
correct autocompletion after letter or two anyway. But when I read
the long names repeated multiple times in expression feel like
stuttering. DRY! That can be matter of taste, I don't know, you do
not show examples.
> I always love it when people give counter-examples by adding
> completely redundant words to the variable names, just for the
> sake of making them longer.
 
I suggested you give examples. Instead you like to critique.
 
> "image_index" is a better name than "index_of_current_image" because
> it doesn't contain redundant information. (The fact that it's also
> shorter is irrelevant. As said, length does not matter.)
 
So your good example is:
for(size_t image_index = 0; image_index < images.size(); ++image_index)
Lot easier than with "i"?
 
> I still fail to undrestand how this is so controversial and worthy of
> such heavy opposition. We are not writing code for the Obfuscated C
> Code Contest here.
 
Simply because I do not see how usage of shorthands causes it to
turn into "Obfuscated C Code Contest".
 
> Mathematics is an extremely poor example because mathematicians are
> almost proud about the fact that their scribbles are as compressed
> and cryptic as possible.
 
Nope. The problems that mathematicians solve are tricky. Their thought
is lot easier to follow when denoted as they do. Writing same using
full english expressions makes it harder to follow for those who can,
and makes it even more mysterious abracadabra for those who can't.
> repeating the same word twenty times makes the code more understanable,
> that's all that matters. The repetition itself is irrelevant. We don't
> need to save disk space.
 
It is misrepresentation. I say the expression becomes less concise
and full of stuttering, you say I want to save disk space.
 
> I could add a kind of corollary to my "use as many words as necessary,
> but no more" sentiment: "Repeat the same name in your code as many
> times as necessary, but no more."
 
OK, but what is necessary? For me it is better to read:
 
auto pI = std::make_unique<Image>(image_file);
 
or
 
auto pI = Image::make_ptr(image_file);
 
Instead of:
 
std::unique_ptr<Image> image_pointer = std::make_unique<Image>(image_file);
 
Latter feels like stuttering of "image" ridiculously many times. I feel
like: "I got it, it is image, stop babbling!" when reading it.
 
> > You are mistaken. Pronouns like it, him, they, there, then are used
> > massively in spoken language.
> They are full words. They are not contractions or acronyms.
 
There are no difference, both cases assume that the reader knows
already what is meant by such pronoun because they did read previous
few lines. If that assumption is incorrect and pronoun can be controversial
then whatever was before was badly formulated. However if it can't be
misunderstood for something else then it helps to comprehend.
> > or legal texts.
> Using mathematics and legal text as examples of "legible" and
> "understandable" text is just hilarious. Legalese is anything but.
 
Good that you noticed! Legalese is anything but understandable
exactly because it tries to be maximally explicit like you seem to
demand, lawyers seem to be paid by text length and so define
shorthands rarely, only to avoid it getting outright comical. Think
about it.
 
> As for spoken language, you don't speak using contractions. You
> speak using full words.
 
If words like "he" or "it" are "full words" or just "shorthands" depends
only on attitude towards those. Between letters and words it is even
more dim. In English there are little to no difference in pronunciation
of "q" and "queue", "t" or "tea", "k" or "key". Nothing to talk of for
example Chinese where every character is "full word" as well. The
whole thing feels like the 40 years ago argument that "begin" is
easier to read than "{". Somehow the proponents of "{" have won.
David Brown <david.brown@hesbynett.no>: Dec 19 02:44PM +0100

On 19/12/2022 09:16, Juha Nieminen wrote:
 
> We don't live in the 1980's anymore, nor are we writing BASIC.
> Bad habits don't become good habits just because they have existed
> for a long time.
 
Sometimes they do. Then they are called "idioms". I don't know if the
use of "i" as an index has ever been considered a bad habit - if so,
perhaps Fourier is the man to blame for using it for summation some 200
years ago. (The bust on Fourier's grave in Paris looks very much like
Voldemort in the Harry Potter films, so perhaps it /is/ evil!)
 
> 'i' is going to index because I don't yet know the intent of that
> for-loop. Additionally, the 'i' buried deep into the for-loop
> body makes it harder to find with a quick visual scan.
 
I think you are exaggerating beyond all bounds of reason. Can you
/really/ claim you think "i" is not clear in a simple "for" loop? This
is not a notation invented by Muttley - it has been standard in almost
every programming language except APL.
 
 
 
>> I guess you've never used SMS.
 
> I don't see you using cryptic abbreviations in your English prose
> here...
 
/Cryptic/ abbreviations are counter-productive. Clear and obvious ones
(clear and obvious from the context, and to the reader) are helpful.
You had no problem understanding "SMS", but it would have taken more
effort to understand what he meant if he had written "short messaging
service".
David Brown <david.brown@hesbynett.no>: Dec 19 02:47PM +0100

On 19/12/2022 13:10, Juha Nieminen wrote:
 
> I cannot understand why you insist so vehemently in defending writing
> cryptic obfsucated code.
 
For the love of $DEITY, will you /please/ read what others are posting,
and stop tilting at windmills?
Bo Persson <bo@bo-persson.se>: Dec 19 10:49AM +0100

On 2022-12-18 at 21:40, Pawel Por wrote:
>> its connection to brace initializers.
 
>> Your class lacks this compiler magic, so works differently (=not supported).
 
> Thank you for response. Is this "magic" somehow available for the users or totally hidden. If so, how can I use it ?
 
I think it is just triggered by the name std::initializer_list. So not
really available for user code.
Muttley@dastardlyhq.com: Dec 19 09:59AM

On Mon, 19 Dec 2022 10:49:14 +0100
>totally hidden. If so, how can I use it ?
 
>I think it is just triggered by the name std::initializer_list. So not
>really available for user code.
 
A bit like printf() is usually a compiler built-in which means it can give
warnings about mismatched format specifiers and parameter types, which it
won't do with user written vararg functions.
Muttley@dastardlyhq.com: Dec 19 09:43AM

On Sat, 17 Dec 2022 13:15:04 -0800
 
>> Something that perhaps 15% of non-commercial pickup truck owners actually do.
 
>Towing a boat up and down to Lake Tahoe from Carson City, one needs a
>vehicle than can do it.
 
Depends how big the boat is. A modern mini can tow 1.5 tons which will cover
a lot small boats + trailer. A lot of larger cars such as a 5 series can tow
2 tons. The only genuine reason for a pickup is if you need to carry a lot of
loose stuff in the bed, and frankly if you do you're probably better off with a
van anyway which will also have a large towing capacity.
Muttley@dastardlyhq.com: Dec 19 09:46AM

On Sat, 17 Dec 2022 19:20:11 -0600
>>> But thats an argument for another newsgroup.
 
>> Ever had to tow a big boat before?
 
>I tow a 5,000 lb 35 foot boom lift two or three times a year. I also
 
A Ford Transit can pull up to 3.5 tons which is 7700lbs.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 09:33AM

You might sometimes hear someone express a sentiment along the lines of
"it's not worth trying to optimize this. What does it matter if it
takes 10 seconds unoptimized while an optimized version could take
5 seconds? Who cares? I can wait for the extra seconds. It's not such
a big deal. A quick&dirty implementation is just fine."
 
But what about an unoptimized quick&dirty implementation taking
*one month* for a task that can be computed in *less than a second*?
 
Recently Matt Parker was wondering about groups of words with no
shared letters and he wrote a program in Python that found all
groups of five words from a dictionary that shared no letters.
His program took a month to run.
 
https://www.youtube.com/watch?v=c33AZBnRHks
 
When he implemented that program he didn't even think that there's
something horribly wrong with that runtime. Any experienced
programmer will have at least a gut instinct that such a task should
run at a minimum in less than a minute, probably in a few seconds,
perhaps even less than a second.
 
It didn't take long for actual programmers to submit their versions
of the program, with the record holder taking less than a tenth of
a second (written in C++).
 
Sometimes optimization *does* matter. Sometimes expertise in programming
and algorithms does make quite a difference. It can be the difference
between the program running for a month vs. running less than a second.
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 18 05:38PM -0600

On 12/18/2022 11:17 AM, Scott Lurndal wrote:
 
> Here's an open-source textbook that goes into the physics of energy
> production and consumption. Pretty bleak.
 
> https://escholarship.org/uc/energy_ambitions
 
You know, at some point we are going to build a partial Dyson sphere
around the Sun to capture its energy.
https://en.wikipedia.org/wiki/Dyson_sphere
 
I still have thoughts about igniting Jupiter but I doubt that we can do it.
 
Lynn
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 18 04:55PM -0800

> We need to accelerate investment in new nuclear build and green hydrogen
[SNIP]
 
This is comp.lang.c++.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 18 03:43PM -0800

On 12/18/2022 2:57 PM, Siri Cruise wrote:
 
>> Undefined behavior.
 
> https://www.youtube.com/watch?v=JOiZP8FS5Ww
 
> Saved by zero.
 
No shit! lol. :^)
 
I have worked on some stuff that would detect a divide by zero condition
and altered it before it occurred. It would log the condition, then
change the denominator.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)