Wednesday, December 21, 2022

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

Juha Nieminen <nospam@thanks.invalid>: Dec 21 06:00AM

> But only /one/ person has said that short identifiers are always bad.
 
And there we go again with the length argument, no matter how many times
I repeat that it's not about length.
 
But even if it were, so what? Why is saying such a thing such heresy,
such blasphemy, that when I refuse to recant and see the error of my
ways it deserves such a full-on attack, a gigantic flamewar thread,
insults thrown around, accusations of "narcissism" and whatnot?
 
Why are you doing this? Why is it *so* important to prove me wrong
that you will resort to even question my personality and deliberately
throw insults at me? Can't you see how insane this entire thread is?
 
And all this for a sentiment that's pretty common, as seen by many
coding guidelines out there, used by big companies.
 
It's actually very easy to find such coding guidelines, ie. ones that
recommend against excessive use of abbreviations and acronyms, and to
use full words instead. It took me just a few seconds of googling.
 
Try to find a coding style guideline that recommends the opposite, ie.
what you are advocating. In other words, one that recommends *against*
using full words in identifier names and instead recommends using
abbreviations and acronyms in their stead. Such a guideline might
exist, but I won't be holding my breath.
 
So why are you doing this? Why is it so important to you? Why are
you ready to fight to try to prove me wrong?
Juha Nieminen <nospam@thanks.invalid>: Dec 21 06:10AM

> Juha Nieminen <nospam@thanks.invalid> wrote:
>>For example, Microsoft's coding guideline says:
 
> I doubt many people would take much notice on MS's opinion on coding.
 
I was wondering how you would try to spin it.
 
Anyway, my point is that what I have written in this thread is a
relatively common principle. You can find many coding guidelines
out there, including those used by large companies, that repeat
the same sentiments I have been saying here, to one extent or
another.
 
I am *not* "the only one who thinks like this". It's actually a bit
hilarious that you accused me of "narcissism" because you said that
I think I have come up with something unique that nobody else has
ever thought of before, when in fact it's the exact opposite: *You*
seem to be the one who believes I am the only person in the world
who thinks like this, while *I* am assering that I am merely confirming
a quite commonly held sentiment.
 
And when I show actual examples of other people repeating this
sentiment independently, you just dismiss it rather than getting
the point (ie. that I am not "the only one").
 
 
> Yet oddly at least 3 generations of unix devs have coped with abbreviated
> posix function names such as ioctl(), getuid(), uname() etc without struggling
> to understand the code. Not to mention standard C functions such as fopen().
 
Actually the original reason why the oldest names in Unix are at most
6 characters long is because the first C compilers had that limitation.
The limitation was quickly increased by newer compilers, but the (bad)
habit of using 6-character names persisted for quite long. A strong
instinct of "backwards compatibility with older compilers". Only
relatively slowly did developers start daring to use longer names.
 
POSIX didn't want to change the established names, so it just took them
as-is, which unfortunately has cemented them to this day.
 
But anyway, people instinctively shortening and abbreviating names doesn't
make it a good coding practice. Just because we have had to "cope" with
those abbreviated names (which is indeed the case) doesn't mean it's a
good thing.
Juha Nieminen <nospam@thanks.invalid>: Dec 21 06:12AM

> Listen carefully - do you hear that whooshing sound? It's the sound of
> the point flying /way/ over your head.
 
Says the person who keeps repeating the length argument over and over
and over, no matter how many times I say, quite explicitly, that it's
not about the length.
Juha Nieminen <nospam@thanks.invalid>: Dec 21 06:30AM

> Overuse of "i" has bothered me too but naming it "index" is even
> more pointless than "i",
 
I don't think it's pointless. Sure, it's not the best possible name
because it's not telling *what* it's indexing, just that it's an index
variable... but even that is better than just 'i'. Perhaps not orders
of magnitude better, but still better.
 
One of the reasons why it's better is that it's more visible in the
code where it's used. You can more easily find it with a quick visual
scan. When reading the code, it's quite literally telling you what
it's doing, and is easier to see where it's doing that.
 
Of course even better would be if it's telling you more precisely
what it's indexing, because that removes yet another layer of having
to interpret this meaning. If it's a row index, then "row_index" is
significantly better than "index".
 
> "i" however "row_index" or "row_number" does feel uselessly long,
> especially if it appears several times in an expression and is clear
> from context.
 
"r" is not much better than "i" because "r" doesn't tell me anything.
It's just a letter. All by itself it doesn't express what it's
representing. "row_index", however, is *enormously* better than
either because it is directly telling me what it's being used for,
what it represents, and thus it helps reading the code. The fact
that it's longer than a single letter is rather irrelevant. What
matters is how clearly it expresses its meaning. (Although the
length is in a way something that helps a bit because, as mentioned
easlier, it helps seeing where it's being used with a quick visual
scan. However, this is not the most important aspect of it, just
a small additional bonus.)
 
If there are eg. only two names being used in the loop, then perhaps
the amount of visual help that naming it "row_index" might be less,
because there's less information to read and interpret in the code.
However, the more names and expressions there are, the more it helps
that it's clearly named, and thus more easy to distinguish and
understand from the other names and symbols.
 
But even if there are just two names being used in the loop code,
it still doesn't hurt to use the clearer variable name, so why not.
I see no problem. We aren't trying to save disk space here.
 
> of temperatures, times and tickets then naming any of those "t" is
> ambiguous. But if it deals with only one of those then it is quite
> obvious local shorthand.
 
Not every single piece of code can be written in three simple lines.
code blocks sometimes become long by necessity, and sometimes they
use a lot of identifier names all over the place. If these dozens
of identifier names are all one or two characters, it becomes a
jumbled mess. However, if they are clearly named, telling directly
and easily what they mean, it makes the code so much easier to
read. It does actually help.
 
I just cannot see the disadvantage of using clearer names. This shouldn't
be a controversial point of view (and is, in fact, a quite commonly
repeated principle eg. in many coding style guidelines).
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 20 10:31PM -0800

On 12/20/2022 10:12 PM, Juha Nieminen wrote:
 
> Says the person who keeps repeating the length argument over and over
> and over, no matter how many times I say, quite explicitly, that it's
> not about the length.
 
Fwiw, David and I got into a "heated" argument a while back about, iirc,
memory barriers and/or atomics. For some damn reason I cannot totally
remember it at this moment, brain fry? Damn. Anyway, we resolved the
issue in a kind manner, and all is good. I wonder if I can find the
thread. Well, not now. Working on other things. Have an xbox controller
to program into my 3d work right now. GLFW's joystick capability. Need
to learn all about it. :^)
 
This thread is getting a bit _hot_.
 
I posted some of my personal code to the thread get it torn apart as
some point of pressure_relief for the thread itself.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 20 10:36PM -0800

On 12/20/2022 10:30 PM, Juha Nieminen wrote:
>> "i" however "row_index" or "row_number" does feel uselessly long,
>> especially if it appears several times in an expression and is clear
>> from context.[...]
 
I use x, y and z as indices in the loop that builds an n-ary unit grid
inside of a unit cube. I posted my personal code for the function that
builds it.
Juha Nieminen <nospam@thanks.invalid>: Dec 21 06:41AM

> This thread is getting a bit _hot_.
 
In all honesty I cannot really understand why.
 
Nothing of what I have written is in any way controversial or worthy
of heavy opposition. As I mentioned elsewhere, it's actually quite
commonly agreed eg. in coding style guidelines (at least the part
of avoiding excessive use of acronyms and using full words instead
which, ironically, seems to be the biggest source of contention here.)
 
There's nothing controversial or horrendous about it, so why all this?
I honestly cannot understand.
Juha Nieminen <nospam@thanks.invalid>: Dec 21 08:24AM

> I use x, y and z as indices in the loop that builds an n-ary unit grid
> inside of a unit cube. I posted my personal code for the function that
> builds it.
 
I tend to use "x", "y" and "z" only if they represent actual cartesian
coordinates (either as integers or floating point). If I'm using them
as some kind of indices to a 2-dimensional (or 3-dimensional) array,
I tend to make it more explicit that they are indices and not really
coordinates (although I admit sometimes, in some cases, the distinction
can be bit artificial.)
 
But I do make the distinction especially if the code uses both index
variables and cartesian coordinates. Oftentimes this is the case when
dealing with bitmap images, where the pixel coordinates do not
necessarily correspond to the cartesian coordinates. For example:
 
for(int yIndex = 0; yIndex < image.height(); ++yIndex)
{
double y = (image.height()/2 - yIndex) * scaling_factor;
 
for(int xIndex = 0; xIndex < image.width(); ++xIndex)
{
double x = (xIndex - image.width()/2) * scaling_factor;
 
// code that uses (x, y)
// and writes to image[yIndex][xIndex]
}
}
David Brown <david.brown@hesbynett.no>: Dec 21 10:32AM +0100

On 21/12/2022 07:00, Juha Nieminen wrote:
 
> So why are you doing this? Why is it so important to you? Why are
> you ready to fight to try to prove me wrong?
 
I'd rather you understood better about how to write code that is legible
and easily understood. I'd rather /everyone/ did that better - we can
all get better at that.
 
I'd rather you did not encourage people to write code that is harder to
read because you /think/ it is easier. While you continually doubt /my/
motives, I have no doubts about yours. Your aims are great - it's how
you try to achieve them that is /sometimes/ wrong.
 
I also find it frustrating when someone apparently cannot comprehend
what others are saying. You've got yourself so tied up in a knot of
anger and irritation in this thread that you don't understand that for
the most part, everyone /agrees/ with you. We all want more legible
code, and we all want better choices of identifiers.
 
But rules like "always use full words in identifiers", "never use
abbreviations", "never use using namespace", "never use auto" - these
are all counter-productive. They lead to /bad/ code that is hard to
follow, hard to maintain, hard to re-use, and easy to get wrong. They
are exactly as bad as a rule that said "always use short identifiers" or
"always use auto".
 
Good programming is a craft - it is not a matter of mindlessly following
rules. Naming identifiers well is a vital part of that, but just as the
"ideal" identifier is sometimes several words long, sometimes it is just
one character. Knowing when to use features like "using namespace" and
"auto" to improve code legibility is part of that - as is knowing when
to use abbreviations or short identifiers. These are just as important
as knowing when to give namespaces and types explicitly and when to use
more descriptive identifiers. And knowing that the choices and balances
can be hugely different in different circumstances is vital to that.
 
I am not interested in "proving you wrong", and I am certainly not
interested in arguing for its own sake. I have the same goals you have
- better software development through more legible code that is easier
to understand. That way fewer mistakes are made, and more of the
mistakes get found.
 
But in order to be better at this, you have to let go of your absolute
rules - going too far in any direction is almost always a bad idea. And
you have to appreciate that code must be understood in its context - the
function, the class, the file, the program - not line by line. Thus an
emphasis on making each /line/ easily understood will be detrimental to
making the /code/ easily understood.
 
 
I imagine that when you write code yourself, you write in a way that is
clear by almost anyone's standards. But if you espouse guidelines like
"always use descriptive names with full English language words", others
are going to take your words to heart and take them to extremes. I've
seen plenty of code where such long descriptive identifiers are used
that programmers fail to type them correctly - leading to multiple
identifiers that should be the same, but have different capitalisations,
different grammatical details, or different spelling mistakes.
 
 
The worst that can happen is that someone listens to your advice and
tries to follow it too far, ending up on the Daily WTF:
 
<https://thedailywtf.com/articles/get_words_from_a_number_which_is_passed_as_a_perimeter_into_this_function>
Ralf Goertz <me@myprovider.invalid>: Dec 21 11:22AM +0100

Am Tue, 20 Dec 2022 17:56:21 +0100
 
> The code was nicely formatted, including comments line-up, before
> posting. It's evidently Thunderbird fouling up things. Maintained by
> script kiddies, no doubt, because WE are too lazy to do such things.
 
It came to me nicely formatted (except for added line breaks in long
lines). So I guess there is some other problem.
David Brown <david.brown@hesbynett.no>: Dec 21 11:25AM +0100

On 21/12/2022 07:41, Juha Nieminen wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> This thread is getting a bit _hot_.
 
Agreed. I will try to be more polite here. (To be clear, I have
enormous respect for Juha - if I didn't, I wouldn't be trying to have
this conversation.)
 
> which, ironically, seems to be the biggest source of contention here.)
 
> There's nothing controversial or horrendous about it, so why all this?
> I honestly cannot understand.
 
I think perhaps part of the issue is that you really cannot understand
why some of what you are writing /is/ controversial. I think perhaps it
is because your /aims/ are not controversial - we all think good, clear,
readable and easily understandable good is a good thing. But we
disagree on certain aspects of how to make code understandable.
 
And yes, there has been far too much repetition and missing each others'
points. There has been little consensus on exactly where we agree and
where we disagree, and we really need that if any progress is going to
be made.
Muttley@dastardlyhq.com: Dec 21 10:26AM

On Tue, 20 Dec 2022 20:29:02 +0200
>> to understand the code. Not to mention standard C functions such as fopen().
 
>I recall the authors of those names are generally happy with them,
>except for one abbreviation: creat().
 
Yes, that is a bit of an odd one. Perhaps they thought that "create" would be
a name people would want to use a lot for their own function names.
Muttley@dastardlyhq.com: Dec 21 10:35AM

On Wed, 21 Dec 2022 06:10:55 -0000 (UTC)
>make it a good coding practice. Just because we have had to "cope" with
>those abbreviated names (which is indeed the case) doesn't mean it's a
>good thing.
 
I've never felt I've had to "cope". Not having to spell out long winded
function names is a positive for me. ioctl is much simpler than
InputOutputControl and once you know it is just as descriptive.
Juha Nieminen <nospam@thanks.invalid>: Dec 21 11:05AM


> I've never felt I've had to "cope". Not having to spell out long winded
> function names is a positive for me. ioctl is much simpler than
> InputOutputControl and once you know it is just as descriptive.
 
For the millionth time: Clear names are not for your sake, the programmer.
They are for the sake of the reader. The person reading your code who
can't read your mind and has to decipher from your code what it's
doing.
 
It has absolutely nothing to do with "having to spell out" anything.
It has everything to with making your code understandable. You may
disagree on what makes code readable and understandable, but please
for the sake of everything that's holy and sacred, do finally
understand what I'm saying.
 
If you want to write good code, the onus is on *you* to make it
as easy for the reader to understand your code. The onus is not
on the reader to try to decipher your code.
Juha Nieminen <nospam@thanks.invalid>: Dec 21 11:11AM

> follow, hard to maintain, hard to re-use, and easy to get wrong. They
> are exactly as bad as a rule that said "always use short identifiers" or
> "always use auto".
 
There's just so much wrong with that, that I'm not even going to bother
to try to repeat what I have already said a hundred times in this thread.
 
I think it's rather telling that what I am saying can be quite easily
found in many coding style guidelines out there, including those used
by big companies. You'd have very hard time finding a single coding
style guideline that's saying what you are saying there, that says
that abbreviations and acronyms are preferred over full words.
 
Why do you think that is?
 
At the very most you could argue that *it makes no difference*
in terms of readability. However, to outright state that using
full words makes code *less* readable and understandable than
using cryptic abbreviations and acronyms is just asinine.
I'm sorry, but it just is.
 
If you think that abbreviating and acronymizing everything
makes text more readable, I dare you to do that to your own
text here. Let's see how much more readable it becomes.
(Won't be holding my breath, though.)
Muttley@dastardlyhq.com: Dec 21 11:13AM

On Wed, 21 Dec 2022 11:05:13 -0000 (UTC)
>They are for the sake of the reader. The person reading your code who
>can't read your mind and has to decipher from your code what it's
>doing.
 
There's a happy medium. LongJavaStyleFunctionNamesThatSometimesWrapOntoThe
NextLine() are just as bad as f().
Juha Nieminen <nospam@thanks.invalid>: Dec 21 11:14AM

> I think perhaps part of the issue is that you really cannot understand
> why some of what you are writing /is/ controversial.
 
Yeah, very controversial. "Use full English words in identifier names
instead of abbreviations and acronyms." What a controversial statement
to make!
 
So many controversial code style guidelines out there. How dare they!
They must be taken down!
Juha Nieminen <nospam@thanks.invalid>: Dec 21 11:21AM

> There's a happy medium. LongJavaStyleFunctionNamesThatSometimesWrapOntoThe
> NextLine() are just as bad as f().
 
How many times will you keep repeating the length argument, no matter
how many times I repeat that it's not about the length?
 
There's nothing in "use full English words, and use as many words as
necessary to express what the thing is doing" that implies "artificially
make the names as long as possible".
 
If you can clearly express the role of the name in one word, do so.
If you need two words to do so, then use two words. If you don't
need three words to do that, then don't artificially use three words.
Avoid redundancy. The length of the words isn't relevant, as long as
they are clear English words. The length of the entire name isn't
relevant, as long as it expresses as clearly and unambiguously as
feasible what the name is for.
 
When identifier names clearly express what they are doing, it makes
reading the code easier. It's that simple. You can argue against that
notion all you want, that will not change the fact.
 
This isn't controversial. You can find plenty of coding style
guidelines out there that state this very thing.
David Brown <david.brown@hesbynett.no>: Dec 21 01:05PM +0100

On 21/12/2022 12:11, Juha Nieminen wrote:
 
> If you think that abbreviating and acronymizing everything
> makes text more readable, I dare you to do that to your own
> text here.
 
If you think that is anything close to what I wrote, then I can see why
you are having such problems understanding this thread.
 
As far as I can tell, you are having trouble appreciating that the
opposite of "always do X" is "/sometimes/ don't do X". It is not "never
do X". The opposite of "never do X" is "/sometimes/ do X", not "always
do X".
 
I fully believe you understand this logic - but you are failing to apply
it here. (This is a common problem in discussions when people get
carried away or worked up about something.) I am not trying to be
patronising here. I just want you to slow down and think about this.
 
 
I say it is wrong to have a rule "always write full words and
descriptive identifiers" because it is /sometimes/ better to use short
forms and acronyms.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Dec 20 09:31PM -0800

On 12/20/2022 12:46 PM, Andrey Tarasevich wrote:
> _how_ you attempt to produce an out-of-range value in it. For example,
> assignment is one thing, while side effect of `++` is a completely
> different thing.
 
... although here I'm probably trying to be too smart for my own good:
there's no need for this kind of branching. In the end, side effects
modify the variable value through assignment as well.
 
This means that trying to "set an int to a value beyond its range"
results in a congruent value in C++ and in an implementation-defined
value or a signal in C. Overflow-related undefined behaviors that can
still occur in signed integer arithmetic are not relevant to this
question, since they are not really related to "setting" a variable value.
 
One can still note though that trying to set an int variable to an
overly large floating-point value results in UB. Although even here one
can argue that the UB occurs as part of the conversion, which happens
before the actual "setting".
 
--
Best regards,
Andrey
David Brown <david.brown@hesbynett.no>: Dec 21 12:02PM +0100

On 21/12/2022 06:31, Andrey Tarasevich wrote:
>> assignment is one thing, while side effect of `++` is a completely
>> different thing.
 
> ... although here I'm probably trying to be too smart for my own good:
 
I think we are all trying to be "smart" here - whether we are being
/too/ smart is an open question!
 
> overly large floating-point value results in UB. Although even here one
> can argue that the UB occurs as part of the conversion, which happens
> before the actual "setting".
 
I think there are three things to consider here. First, there is the
issue of what the OP meant. Then there are the two different ways to
set the value of a variable.
 
Regarding the OP's intention - while this is speculation, I believe he
was thinking of signed integer overflow in arithmetic expressions -
overflow in the addition part of "x = a + b;" rather than in the
assignment part. And in that case, signed integer overflow is undefined
behaviour in C and C++, and many compilers optimise on the assumption
that it never happens. (A few compilers, like "gcc -fwrapv", give it
defined behaviour.)
 
Setting a variable explicitly (whether it be by initialisation,
assignment, augmented assignment, or increment/decrement operator
side-effects) is a matter of conversion. For an integer type to an int,
this is covered in 6.3.1.3. If the value to be converted cannot be
represented in the new type (int, in this case), "either the
result is implementation-defined or an implementation-defined signal is
raised." For almost all compilers, excluding sanitizers or special
debug modes, this is done by two's complement wrapping.
 
Conversion from a floating point number that is out of range is
undefined behaviour.
 
 
The other way to change a variable is using memcpy, a character pointer,
or a union. These methods affect the underlying representation
directly, and do not operate on values - so "overflow" or "range" makes
no sense. You can get undefined behaviour later when the value is read,
if it is a trap or otherwise does not represent a valid value of the
type. (You won't see that with integers, in real-world compilers - but
you can see it if you set a _Bool variable to something other than 0 or
1 using memcpy() or a char pointer.)
Louis Krupp <lkrupp@invalid.pssw.com.invalid>: Dec 21 03:44AM -0700

On 12/20/2022 11:01 AM, Frederick Virchanza Gotham wrote:
> return true;
> }
> [end code]
 
<snip>
 
To quote Shakespeare, who knew a thing or two about trusting people too
much and then living with the consequences:
 
"... that way madness lies ..."
 
Louis
Juha Nieminen <nospam@thanks.invalid>: Dec 21 06:35AM

> auto fp = [] (vector<int> vi)
 
By the way, you should almost never take class instances like this
as function parameters by value. You should almost always take them
as const reference.
 
When you take it by value like that, it will be *copied* for the
function. The larger the vector is, the heavier it becomes to copy.
In most cases (like here) the function doesn't need a copy of the
vector. A reference to the original suffices (and passing a reference
as parameter to the function is infinitely more efficient than
copying the entire vector).
 
The only case where you want to pass such an object by value instead
of by reference is when the function actually needs a deep-copy of
the object, but that's quite rare. (Even in such cases it's actually
usually better to still take the parameter by const reference and
copy it inside the function.)
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 20 05:51PM -0600

On 12/20/2022 8:49 AM, Scott Lurndal wrote:
 
>> I cannot remember the model of the boat, a Cobalt perhaps?
 
> The article indicated it was a 37,000 pound yacht. 8 tons beyond the
> towing capacity of the F350. Driver got 3 to 10.
 
Wow, I used to pull a 28,000 lb gooseneck with a C30 dually and then a
F350 dually. The trailer was an incredible handful and the brakes were
definitely a serious concern. We were considering buying a Class 8
tractor when I left the group.
 
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 20 05:52PM -0600

> engine its got but then you guys also allow geriatrics with only a car license
> to drive 10 ton converted buses (also known as RVs) and towing a car to boot!
 
> I guess in the US safety comes a poor 2nd place to lifestyle.
 
I've seen those geriatrics towing a boat AND a car behind an RV. The
whole train is about 60 to 70 feet long.
 
Lynn
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)