Coercion dots, do you even care in the "real" world (eg. you 'fix' them all)? Why or why not and when or when not?

[DoctorAutomatic]

Like many an eager young LV pupil, I was initially taught "coercion dot = BAD!!!".

After many years of LabView I lean the other way (eg. Coercion dots are much ado about nothing among professionals). After years of viewing code written by people that I considered far more advanced than myself, even pillars of this forum that we all know and acknowledge to be god-like experts, not bother with "fixing" coercion dots, at some point I too stopped bothering with thinking twice about them. And yet, I have never, NEVER, been bit a single time for not "fixing" one (which, is exactly what coercion does except in cases that only arise from other poor decisions or root causes). This further reinforces to me that coercion = shmoercion, who really cares? Noobs? Haha, right?

On the one hand it seems obvious to me that one should understand why there's a coercion of type, and there are times where that should alert you to something very bad, but in most cases it means you chose the wrong data type initially.

Now you might recall some physical catastrophe caused by such a programming error, but that's an argument for a more strict type system in Labview (ie. broken run arrow), and I'm not saying get rid of coercion dots, just wondering out loud whether the hoopla about them, the scarlet letter 'C' you are made to believe you will wear if you don't fix them, is possibly outdated. Remember how an error case structure around every VI used to be orthodoxy? How many years of cumulative developer time has been wasted on that? Seems sort of the same for coercion dots on mundane and inconsequential coercions. To say nothing about the additional clutter of explicit conversions wherever a coercion dot exists.

soooo... agree, disagree? Thoughts, comments? And be honest, in real life, do you actually consider code with scarlet dots unacceptable? I'll go microwave some popcorn and get my fire extinguisher in the meantime...

😉

[rolfk]

I tend to be pretty serious about avoiding coercion dots and they are set to be bright red. But I’m not fanatical about it. There are places where a coercion dot is evil and if I see them on such places I know the original programmer was a noob and would not hesitate to say so straight in their face.

-on an array, especially if it can get really large

- inside of loops that can run millions of times

- in FGA code if not carefully reviewed to be neccessary

Anything else such as small arrays and especially on scalars is usually harmless, but it doesn’t mean you should mix and match every possible datatype on a diagram, keep it consistent and if you see a diagram with more than a few coercion dots stop and think for a minute how to change it to avoid some of them. Sometimes it’s easy and changing one or two things can get rid of half a dozen or more coercion dots. But when you start to get one new coercion  for dvery one you can extinguish you reached the point where you have to stop. There is a good chance you implemented a rather bad algorithm too in such a case, but sometimes bad is good enough if it works (and you can proof it with unit tests). 😀

It all depends on what it is used for too. A one off test routine or proof of concept requires less perfection than a routine for an application! But if if is for a reuse library you need the highest perfection you can possibly handle!

”Fixing” coercion dots with an explicit conversion is usually not only nonsense but can be even harmful. In terms of performance it is the same extra overhead as the coercion dot you replace but in a diagram with shift registers or feedback nodes it can be very helpful if you can force the datatype to a specific type that might magically fix many coercions at once with a single conversion. Use of conversion nodes AWAYS should be deliberate and after serious consideration, NEVER just to fix a coercion dot!

[altenbach]

Why not start reading my discussion from 15 years ago 😄

Read the entire thread....

(Sometimes an explicit conversion is less efficient than a coercion dots)

[Jay14159265]

It's like the engine warning light on your car, sometimes it pops up because you need an oil change, other times it means you will soon need to re-build your entire engine. 

hmm the snip does not capture the second coercion dot, curios. 

 

 

[paul_a_cardinale]

Coercion dots are warnings.  That's how I treat them.  If I see one, I make sure that I understand why it's there.  I don't try to get rid of it unless keeping it would cause trouble.

[Andrey_Dmitriev]

---

@DoctorAutomatic  a écrit :

Like many an eager young LV pupil, I was initially taught "coercion dot = BAD!!!".

---

This is why I always say that learning LabVIEW as the first programming language is not the best idea. It's better to learn a classical old-school typed language first, (where variables are required to have a declared type), and where you would get a normal warning in such cases:

Personally, I have had a more or less "classical" education path: Fortran -> Pascal -> C -> ... and because of that, the question "What are coercion dots, why and how should I deal with them, etc?" has never been raised for me at all.