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?
@crossrulz wrote:
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.
This with a small addition.
As crossrulz says, coercion dots are a warning, that prompts me to stop a second and trying to understand why they occur. If they can easily be avoided by making somewhere a different datatype choice or forcing a specific datatype at some point, I definitely will do that. If it seems more effort than that it will depend on the location. In scalars I simply leave it at that and concentrate on more useful points to improve the application. If it is however in an array or in a loop that gets executed many million times, I always will spend a little more time on it to see if there is a possibility to improve things.
Coercions are an indication that LabVIEW is very likely doing extra runtime effort at that point. If this happens a few dozen times in a typical application execution, you really won't even be able to measure that extra performance loss. But if this goes into many million times, it may be the difference between a snappy application and a snail.
Sometimes I do it on purpose, as writing 2 to a Disable property instead of "Greyed & Disabled". Sometimes they are a great warning/heads up.
As many others have said, it really depends on the type of work you do. IMHO, it's best to learn to avoid at all costs until you learn when you CAN avoid them.
Two cases where they're (almost) required to get fixed:
1- When you're doing some array indexing and run into an overflow. Automatically casting between signed and unsigned is usually fine, until your user doesn't apply a setting correctly, and you wind up with a For loop iterating a few million times 🙂
2- When you're doing data flattening and unflattening and you require bit-perfect data representation (which is a VERY common scenario in my job). I have to be very meticulous about managing types, and any conversion between types needs to be handled very carefully. A coercion dot means that something got missed somewhere, and I need to see what I did wrong. Granted, this is unlikely to be a common case for most people.
Usually the fix for a coercion dot is to figure out what got mixed up, then fix the upstream code. If it really is a simple coercion, I'll usually throw in an explicit coercion, but it's more of a "comment" than a programming feature. It lets future programmers know that yes, I understand these types are mismatched, and I have reviewed the consequences and understand that it's OK.
For something trivial like a float multiplied by a scalar, then I'll ignore it.
@BertMcMahan wrote:
it's best to learn to avoid at all costs until you learn when you CAN avoid them.
That's a good way of putting it! "Learn the rules before you break them!"
