IF CASE THEN GOTO - deprecate them all?
GOTO is evil, it should not be used, I am not going to advocate that we should have GOTO or that we should enjoy not having the GOTO keyword. Let's look at the Z80 or the 8085/8086 CPU instructions that have all of the Jumps, JP, JPZ, JPNZ, JPP, JPPO, JPNC, JPC and then the same set with CALL. The OPCode JP stands for Jump (acts like GOTO) which basically moves the instruction pointer to a new location either relatively or implicitly. While the CALL is used to move the instruction pointer to a new location, but prior to that is pushes the current details onto the stack and then when the calling function encounters a RET of some sort, it resumes execution from the last point where the CALL was invoked from. This is like a GOSUB or calling a function that returns and continues the operation. With the x86 nothing much has changed, it is similar also with the ARM processors the only difference being that it has a reduced instruction set rather than opcodes for each condition.
In this article we shall not be learning about Assembly, which would be fun but we'll keep it for another article in the future. The purpose of this article is also not about considering the options of how GOTO was deemed evil and stopped, removed from a lot of languages but still trails in the form of while loops and such other forms. It is looking at the IF conditions or statements and the switch case option and which one of them work better and their comparative advantages and disadvantages.
Let's look at this code
and consider the alternative with a select
both do the same thing, then which one is better and why?
if you do not have all the enums in the switch block, the compiler complains that the switch is not exhaustive and all the cases must be considered. Using a default acts like the else in an IF or for all other undeclared cases.
consider the following code, this is for illustrative purposes only, this is not the most optimal code
I like this approach because it allows to set up enums in a single file and can extend it for as many cases.
In fact, just a while ago I have refactored code for a client changing a tableView code to work off an enum, with the enum extending and providing things like row heights, icons, colors, data, etc. This approach made the code modular and better in comparison to what was written. It helped move all of the code into the enum block which was otherwise a series of if's in the UITableView methods.
In this article we shall not be learning about Assembly, which would be fun but we'll keep it for another article in the future. The purpose of this article is also not about considering the options of how GOTO was deemed evil and stopped, removed from a lot of languages but still trails in the form of while loops and such other forms. It is looking at the IF conditions or statements and the switch case option and which one of them work better and their comparative advantages and disadvantages.
This belongs to the Academic Textbooks
Yes, though this is very very basic it is still a discussion on the usage of IF statements and how they are bad, I had an earlier article that spoke about the Ternary operator (?) which was used in C type languages and still used with JavaScript and other modern languages which is now being discussed to be deprecated from the Swift codebase just like the ++ operators.Let's look at this code
if (aState == 1) { print("State 1") } else if (aState == 2) { print("State 2") } else { print("State Else") }
and consider the alternative with a select
switch aState { case 1: print("State 1") case 2: print("State 2") default: print("State Else") }
both do the same thing, then which one is better and why?
Using enums in Switch
lets look at the same code with using enumsenum States { case stateOne case stateTwo case StateThree } let aState: States = .stateTwo switch aState { case .stateOne: print("State One") case .stateTwo: print("State Two") case .stateThree: print("State Three") }
if you do not have all the enums in the switch block, the compiler complains that the switch is not exhaustive and all the cases must be considered. Using a default acts like the else in an IF or for all other undeclared cases.
My perspective
Each of us is entitled to an opinion, mine on this matter is that I do not have a favorite and am happy to use both IF and Switch as per the situation demands. Though the enums are a personal preference given that in swift they are slightly more than simple enumerations. Given that they can have values and functions, they work out slightly better than a simple if.consider the following code, this is for illustrative purposes only, this is not the most optimal code
enum States { case stateOne case stateTwo case stateThree } extenstion States { func perform() { switch self { case .stateOne: print(" 2 x 2 = 4") case .stateTwo: print(" 5 x 5 = 25") case .stateThree: print(arc4random()) } } } let aState: States = .stateOne aState.perform() }
I like this approach because it allows to set up enums in a single file and can extend it for as many cases.
In fact, just a while ago I have refactored code for a client changing a tableView code to work off an enum, with the enum extending and providing things like row heights, icons, colors, data, etc. This approach made the code modular and better in comparison to what was written. It helped move all of the code into the enum block which was otherwise a series of if's in the UITableView methods.
Comments
Post a Comment