03-31-2014 02:25 AM
This is a purely academic question...
I have recently started work with a new team at a new company, and one of the first things I noticed about their LabVIEW code was that they very often used strings for case structure selector control. On other teams I have experience with I have seen the use of enums (a lot), numbers, and booleans. Only very rarely do I recall seeing strings used much.
I always thought (and I guess I thought most people also thought) strings just made things difficult because it is hard to tell just what string might be sent to a case, since any string not explicitly called out in it's own case will use the default case, which is required when using strings. Not to mention type-os, case sensitivity issues, etc. On the other hand, with enums you can use the "add case for every value" feature, you don't need a default case, all possible received values are obvious, there is no chance of type-os, etc. I thought for sure I saw this mentioned in the past in the style guide, or one of the classes, but I can't seem to find it.
Fortunately, the team lead doesn't force anyone to code this way, so I will just keep using enums, but everyone on this team seems to think using strings is a good way to go, so I now wonder if I have previously been working on teams that did things odd, or is this team doing things odd. I thought this might call for an informal poll, so if any of you don't mind answering:
How do you usually control cases structures in your code (particularly enum vs string), and why do you use the method that you do?
03-31-2014 02:46 AM - edited 03-31-2014 02:46 AM
The JKI state machine uses strings and I think there was a discussion why this choice was made. You can configure the cases for case-insensitive match, eliminating one of the problems you mentioned.
Strings are more flexible for a generic template such as this.
All that said, I typically use enums. However enums need to be customized for each specific use case.
See also this diiscussion.
03-31-2014 03:44 AM
There is also one advantage you gain by using strings above other data types: Interface flexibility.
Using strings, the interface to your statemachine can be queues, TCP and other protocols working string-based without the need to "morph" commands/requests to a specific data type.
Norbert
03-31-2014 06:21 AM
I recently started using strings for my state machines. I do find it more flexible. But the big advantage for strings I found is that you can easily add parameters to your state calls. Yes, you could do the same with an enum/variant cluster. But strings are so much easier to read. Just choose a good delimeter.
03-31-2014 08:49 AM
I've been writing LV code for over 15 years and for all the reasons you mentioned I've used the enum-based state machine on most of my applications.
03-31-2014 10:04 AM
When making design choice, you are frequently asked to choose between flexibility and maintainability. In the case of state machines, I find that I need to use enums because I can't trust myself with my typing. At least with an enum, if I make a typo, it's reproduced everywhere (much to my chagrin).
03-31-2014 10:14 AM
@billko wrote:
In the case of state machines, I find that I need to use enums because I can't trust myself with my typing.
I totally agree that mis-typing a string can be a problem. Which is why I always have my Default case prompt an error stating the case it was trying to go to, and wasn't found. These types of issues are usually only found once during development, and then fixed. It's not often I am creating strings dynamically for the case. If I need to pass in a parameter I do so through a different mechanism then a string delimiter.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-31-2014 10:58 AM
@Hooovahh wrote:
@billko wrote:
In the case of state machines, I find that I need to use enums because I can't trust myself with my typing.
I totally agree that mis-typing a string can be a problem. Which is why I always have my Default case prompt an error stating the case it was trying to go to, and wasn't found. These types of issues are usually only found once during development, and then fixed. It's not often I am creating strings dynamically for the case. If I need to pass in a parameter I do so through a different mechanism then a string delimiter.
That's funny because I purposely eliminate the default case so it will give me a broken arrow if I add a case to the enum but forget to actually include the case. I admit I'm sometimes too scatterbrained to police myself.
03-31-2014 12:53 PM
So it seems there isn't the consensus I thought there was about whether to use strings or enums. I didn't even think about the JKI state machine. I think this team may have been insipred by that because they like to reuse their state machine code without having to reuse enums.
I think I will still use enums though, as I feel like they make it harder to screw up my code.
03-31-2014 12:57 PM
It's true that it is largely a preference of the developer. Some can say the reasons they don't use strings (or enums) and the other team can defend it with why they do use strings (or enums). LabVIEW ships with examples of both and if you are more familiar with one over the other I'm guessing you'll know the cons of that technique and avoid them.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord