Quote:
|
I still don't understand why an if-statement would be functionally different from case statements at all.
|
An if statement without an else has no way to specify values for the !if cases.
If(x==3) y=4;
When x isn't three, what value will y have? Perhaps y is already initialized, perhaps not, and that is an opportunity for an uninitialized variable. Sure, one x and one y and it is trivial to see, but as things scale, the structure and the usage pattern lead to a very large number of potential problems.
If/else is equivalent, and the documentation and instructors will typically say something to the tune of "If you are familiar with if/else statements in C/Basic, the Boolean switch is the equivalent". Then they should explain that the other case may seem unnecessary, but lets you ensure that the wire-equivalent of y gets a value that you explicitly specify and think through.
Quote:
And then, have a way to right click and attach else ifs to the initial if. I'm actually not sure if I understood this point though. What's the concern with uninitialized variables?
One benefit of this would be that it's easier to visually identify and understand long chained if/elif/elif/elif/elif.../elif statements where you have different conditional in each elif.
Example:
if (a == 1)
else if (b == 2)
else if (c == 3)
else if (d == 4)
An if-elif structure would be 1 structure with 3 squares attached to the bottom. If you're using case statements, you'd stack 4, one in each other. I'd argue the former looks nicer and more intuitive.
|
Right-clicking and arbitrarily adding else ifs to an if is prone to building an incomplete or tangled set of logic. For example, if you have four integer variables, a, b, c, d, and that is the complete logic statement, I'd schedule a code review immediately. That is almost guaranteed to have holes in what it handles and how it handles it. Similarly, a series of nested Boolean cases also raises my eyebrows, but it has a higher chance of being written correctly because of the else's. In all likelihood, the variables need to be transformed first into a more explicit state variable, and the action switch is driven that new value.
The other issues with cascading vertical boxes is that the either cannot have wires that leave their border, or the wire coordination is very unclear. This occurred in Mindstorms NXT. LEGO asked if we could draw the case statement flat, with a simultaneous view of all diagrams. The tradeoff is that wires may not cross the structure boundary. The 3D structure of the case, becomes nasty and difficult to edit and visualize when disassembled and placed into 2D.
For an example of the consideration that goes into extending any language and comparing it to existing de facto standards, here is a paper that describes why object oriented LV was done the way it was done. I don't have a paper for the equivalent thoughts on if/elses and cases, but I'm pretty sure the conversations did take place.
http://www.ni.com/white-paper/3574/en/
Greg McKaskle