We can use a Switch or Ternary statements to make average return a grade is one of them more ideal for this problem? If so why?
To start off, which standard control flow structure do the above two emulate?
If I understand your question they’re emulating Booleans
Are Booleans a ‘control flow structure?’ Take another swing at the question.
if / else statements
1 Like
Right you are. Now, of the three, which ones are expressions?
Recall that an expression can be resolved to a value.
Aside
Taking pooch out for a walk. Back in a short while.
Ternaries & switches meet the criteria to be expressions.
1 Like
Are you sure? Only one of those is an expression. Which one? Think, 'what can we return?
I think I’m unsure of how a value is defined in “can be resolved to a value” which leads to confusion on “what can we return”
The way I currently understand both of them is that they can both accomplish the same goals logic wise but are written differently. Is there a example you could use so I can differentiate them or understand the path you are leading me down.
1 Like
Consider the very simple,
a + b
Better still,
6 + 7
Looking at that we envision, 13. The addition is an expression. In this case one that can be evaluated, thus resolves to a value.
A && ! B
A logical expression resolves to a value.
A ? B : C
The above ternary expression resolves to a value (one of the outcomes).
Notice that all the above values can be written in a return statement. This comes down to the conclusion that ternaries are a suitable choice when they can be returned. They can be useful in value assignments, too, but we need to be clear for the reader.
The core control flow structure, if..else if..else is often the better choice for the sake of the reader, and for portability (porting from one language to another). Not all languages have a switch structure, and neither do they all have ternary expressions. They will all have an if-else. This is not an argument against the other two forms of decision making models, though is does strengthen the argument for if-else.
The switch statement is by some considered to be ‘syntactic sugar’, and little else. If there is a clear argument supporting it over if-else, I haven’t heard it, even while I might have tried to propose one. In the end I fell into the pit and resigned myself to use an object to do the heavy lifting (*) that a switch does. In that event all the above logic goes out the window.
Bottom line, set a base line rule that states, always write the if-else code first and make sure it works as expected. Only then consider whether refactoring first helps you and the reader and second, somehow improves your code model. Don’t use a switch or a ternary as replacements of if-else, but rather suitable substitutions in special cases, such as the above ‘can be returned’ condition for choosing a ternary or resolving a single value out of a selection group for the purpose of assignment.
In the end, we want our code to be consistent, and for readers to be able to understand our code patterns, patterns that we should be setting out for ourselves for re-use over the long term. You will be the best judge in time, if not right at the present.
To repeat, start with if-else all the time, and refactor only if it benefits the program and/or the reader.
* If you have the time, search the forums for the phrase, ‘let objects do the heavy lifting’ and you might come across one or two examples.
2 Likes
Understood, I appreciate the explanation.
1 Like
As I appreciate you sticking it out. Kudos!
Bonus:
> [A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z] = new Array(26).fill("")
<- (26) ['', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '']
> A?B:C?D:E?F:G?H:I?J:K?L:M?N:O?P:Q?R:S?T:U?V:W?X:Y?Z:"Wuhahaha"
<- 'Wuhahaha'
We took this current right to the end. Do you see the potential short circuits? There are 13 of them in this example, given there are 13 ternaries. When we get right down to the mechanics it’s easy to see.
It doesn’t stop there though once we begin to fill out each variable component. It should be stated that the above outcome was only possible because there was no short circuit. This is a special case, and one which can only be reached as the default when there are no short circuits. When carefully crafted one can suppose this is a cool code structure.
One would be wrong. It is only cool to look at, and not much else. It has so many dependencies it makes one’s head shudder. There are so many failure points, where would one begin to debug it?
We can see what this points to: complexity. Really well fashioned code avoids this like the plague. It’s why I stressed earlier about sticking to core models and then massaging out smoother code patterns that a reader can follow and reason with (that includes you in six months).
Just because we can do it in ‘practice’ does not mean we can/would do it in practice. The discretion is all ours, the author. We will be the ones painting the technical value on one structure or another as time progresses. The most we can do in the meantime, and even ongoing is, keep an open mind and don’t fall into traps. When we can see our way forward with a given model then it makes sense to go with it, the proviso being that any model can be improved.