From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Good code rule for casting datatypes
@FrasseKatt wrote:
Wow, I knew there would be so much knowledge and competence in here. So far, thanks for all your contibutions.
When it comes to the actual issue, let me just clarify that it's a good, balanced code rule that I'm looking for. Something catching the risky cases, but not more.
In the code itself, there are probably lots of ways to avoid the risky cases. But right now, I need something for the reviewer to follow.
Just this rule:
Be an expert at understanding how coercion of one data type to another may affect the operation. For example, coercing from an I32 to a U32. Is your code going to properly handle a negative number? (Note, this has nothing to do with whether or not an explicit coercion is needed - the code will behave the same way either way.) Here is where I might add an explicit coercion because they might miss a small dot, but not the (hopefully) coercion node. It will scream at them to "be careful here".
There's no simple answer. You also have to understand what is coming before the coercion. "Is it even possible for the code to produce a negative number?" Sneaky case: If it's an index, it could be (-1), for example.
@FrasseKatt wrote:
After reading all comments here and also discussing with my colleagues, this is currently my draft:
If possible, data types shall be maintained in data processing. Necessary type conversions shall be made without compromising data integrity, e. g. by wrap-around and truncation. A good practice is clarifying comments in the code.
All opinions on this are welcome.
I think you have all the points mentioned throughout this topic. It's formatted like a typical requirement, too. Good job!
