LabVIEW
Coercion dots, do you even care in the "real" world (eg. you 'fix' them all)? Why or why not and when or when not?
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!
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)
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.
@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.
A coercion dot is much better than a broken wire and chances are that LabVIEW knows what needs to be done and just tells you that something happened. Long ago, you had to take a wild guess, but now you can even hover over the coercion dot and it tells you want it got and what it actually wanted. (There are many exceptions where it does not work, but this was not possible at all in ancient version!).
As a result, we can often quickly patch something together and validate the correct result, then do cleanup, simplification and optimization later. This is better than broken code because of a mismatch that does not really matter. (E.g. sometimes we see an orange shift register initialized with a blue zero, That zero could be blue because it started out as orange and the user typed a zero without a decimal point and it adapted to the entered data and the beginner has no idea what happened.)
I am always amazed to see really, really bad LabVIEW code that still works fine. 😄
My general take on coercion dots is that they are a warning. Many times, it just takes me changing the data type of an upstream constant or control. These I definitely take care of as it is a simple optimization. Every once in awhile, I run into a situation where the coercion is not what I need and so I have to explicitly coerce a value to the type I actually need. And then there are a lot of times where a coercion of some type is unavoidable. I tend to leave these coercion dots alone.
