Default cases should be pure!

[altenbach]

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

[altenbach]

Having an extra condition in the default case is highly unusual in any other programming language. There is nothing like an if-else as follows:

if (A) do something

else (or also if B) do something else

or a switch statement as follows:

switch (n)

case 1: do one thing

break

case 5: do another thing

break

default (or also case 3): do yet another thing.

Seems very redundant. 😄

The only thing the current LabVIEW implementation does is break things because of duplicate values, since the default case might be polluted and overloaded.: Entering a specific value in the default case prevents it from being used elsewhere in a specific case.

Is there really a scenario where this would be beneficial?

[Brian_Powell]

I had to go back and try LabVIEW 4 to remind myself how the case structure used to be before we added the "default" case in LabVIEW 5.  In LabVIEW 4, numeric case structures were always non-sparse starting with zero--e.g., a three-diagram case structure had values 0, 1, and 2.  Negative values went to the zero case, larger values went to the last case.  Sufficient to do whatever you need, but not exactly user-friendly.

Conjecture:  When we added the more modern case structure functionality in LabVIEW 5, we wanted to maintain some elements of the old behavior for people who were used to it--such as dropping a case structure with two initial cases.

Can you please clarify whether the case structure should drop with only a "default" case, or whether you want it to be two cases... "1" and "default".

If only a single case, one thing I like about your proposal is that it forces the user into the decision tree early.  It doesn't presume what you want; it just starts with a single diagram and forces the user to think about how to expand it.

The thing I don't like about this is that it is more complex for the user who intends to wire a Boolean or Error Cluster (and I guess enumeration and maybe others).  Those users have to add a case.  Not a big deal, but it brings in the complexity of deciding what to do about converting case structures to/from situations where "default" doesn't make sense.

I'm not ready to kudo this, but it's worth thinking through this some more.  Can you flesh out the details of your proposal?

[altenbach]

Sorry for not being clear enough. 😉

I would like the case structure to always drop with two cases, exactly as we have now, just that the default case should no longer contain any extra specific values in addition to the word "default".

(For backward compatibility, we should be able to add or keep extra conditions in the default case exactly as before. That should still be allowed. Also if we make a new case the default, the extra selector values should not disappear)

This idea should only apply to newly dropped case structures. For example, if I want a structure with two numeric cases "0", and "default" (that's what I always seem to need in my code!), we currently need to do the following:

1. drop the case structure around existing code
2. connect the selector wire   (visible case is "1", other case is "0,default")
3. change the "1" in the visible case to "0"
4. Now the VI breaks because we have duplicate selector values
5. Now we need to make the other case visible
6. Now we need to delete the existing "0" or change it to some other random value that is not used in other cases.

After implemetation of the idea, we can skip a few steps:

1. drop the case structure around existing code
2. connect the selector wire  (visible case is "1", other case is "default")
3. change the "1" in the visible case to "0"

all done with half the effort! 😄

[crossrulz]

I would prefer having a "Default" case and a "0" case instead of the "1" (make it 1/3 the effort )

[stbe]

Nice one, Christian!

I'd suggest to clean up the case structures when connecting ENUMs too. I always hate it to remove either the "Default" string or the element from the combined case selector suggested by LabVIEW.

[David_L]

I love this idea, as I too always remove the extra value in the default case.  I partially agree with Brian that when dropped, only the default case should be created and the programmer must manually add extra cases.  More than likely the value of the second case is not the one that I want to handle, so having to manually create it will make it more intuitive.  For example, I have never wanted to handle the "True" case for a string selector, but this is always created.  

I think this might be annoying for Boolean or Error cases, but perhaps LabVIEW could automatically create a second case when one of these wires is connected.  

[altenbach]

I think we should always get two cases to start out. The only reason to drop a case structure is the fact that we need more than one case (else we would use a sequence frame instead :o). So in 100% of the scenarios, we need a second case anyway.

Also remember that we cannot directly drop a case structure containing a default case, because we always first get a plain boolean true/false case structure when freshly dropped from the palette. Only after hooking up a non-boolean selector, a default case even starts to exist.

I agree with crossrulz that the first case should have the default value for the numeric or enum while the other case should be "default" (wow that sounds confusing, so many instaces of the word "default", but with different contextual meaning...)

[Dragis]

Kudos from me. We actually have this as a coding guideline, but it would be nice if the system just enforced it.

[soupy]

this is pretty trivial detail. not sure why this actually got this many votes...

i think it is very important for the default case to also accept other cases. it give the developer the ability to explicitly denote that a value belongs in the default case. otherwise, the next porgrammer will come along and say "the previous developer is obviously stupid. surely he didn't mean for case 'meh' to be handled by the default case." i use this all the time with enumerated case structures.

I'm quite sure that NI will not implement this feature as it will break backwards compatability for no tangible gain (well maybe an emotional gain for some people).

[altenbach]

> I'm quite sure that NI will not implement this feature as it will break backwards compatability for no tangible gain (well maybe an emotional gain for some people)

Read the idea again as well as comments and clarifications. I never said that the current ways should be disallowed, just that by default, the default case of newly created case structures should not contain any extra conditions initially. You will always be able to add extra conditions to the default case. There is no problem with backwards compatibility.

> this is pretty trivial detail. not sure why this actually got this many votes..

A 50% reduction in programming steps is not trivial (details). 😄 (That's like doubling your hourly wage! 🐵