#If vs switch If-statements and switch-statements are both "selections" (control structure). Selections produce abstractions in the control flow as you loose the information "which way was selected" afterwards.

Using one or the other does not change the control flow. So after all both are either good or evil or anything beneath it. Depending on the programming language they may be different in the assertions they give when mapping a datastructure to a control flow. But if you know that a switch statement serves the same purpose as an if statement readability becomes a matter of habituation and subjectivity. That is why I say also "switch" when I say "if".

You may have new syntactical sugar to express "selections" that will be more compact but it remains a selection.

#Abstraction The only interesting thing we are able to change to a more flexible structure is the abstraction that will be represented as abstract classes or interfaces with their concrete implementations. If you make proper decisions for abstractions they become beneficial (e.g. readability).

#Parsing A combination of the interpreter pattern and the state pattern will provide a solid structure for parsing things from various sources. The state pattern will guide your control flow through different compilation units that can be independently arranged. The interpreter will gather the instructions from the "state machine" and executes whatever it should do.

To be fair: You will finally not have less if-statements and a lot more compilation units. But you will have a beneficial structure that decouples nested if-statements in an elegant way to be able to recompose the control flow. So you will get the flexibility to meet future parsing requirements when extending the interpreted language.

Here we have a beneficial structure that leads objectively to better readability and understandability as a concrete state focussed only one level of if-statements, is isolated from other states (other isolated if statements) and encapsulated. Your internal stack is less loaded to see and understand the movable parts within the state than an equivalent nested If-then-else cascade.

What you do with this is applying the single responsibility principle. A state is responsible to only decide to which state to go next residing in one level of abstraction that definitely is affecting readability.

#References Oracle for example provide state machine like diagrams to define the syntax of their SQL variant:

SELECT (Oracle)

Another representation but effectively the same purpose PostgresSQL Documentation is following within the synopsis:

SELECT (Postgres)

Another way to formalize the syntax in a developers style is using the UML notations for a state chart:

UML state machine

The base theory for all of this are:

Petri nets

A very simple schema to get an idea how to implement it I provided here:

Infix to Postfix Formula Parser Java

If vs switch

If-statements and switch-statements are both "selections" (control structure). Selections produce abstractions in the control flow as you loose the information "which way was selected" afterwards.

Using one or the other does not change the control flow. So after all both are either good or evil or anything beneath it. Depending on the programming language they may be different in the assertions they give when mapping a datastructure to a control flow. But if you know that a switch statement serves the same purpose as an if statement readability becomes a matter of habituation and subjectivity. That is why I say also "switch" when I say "if".

You may have new syntactical sugar to express "selections" that will be more compact but it remains a selection.

Abstraction

The only interesting thing we are able to change to a more flexible structure is the abstraction that will be represented as abstract classes or interfaces with their concrete implementations. If you make proper decisions for abstractions they become beneficial (e.g. readability).

Parsing

A combination of the interpreter pattern and the state pattern will provide a solid structure for parsing things from various sources. The state pattern will guide your control flow through different compilation units that can be independently arranged. The interpreter will gather the instructions from the "state machine" and executes whatever it should do.

To be fair: You will finally not have less if-statements and a lot more compilation units. But you will have a beneficial structure that decouples nested if-statements in an elegant way to be able to recompose the control flow. So you will get the flexibility to meet future parsing requirements when extending the interpreted language.

Here we have a beneficial structure that leads objectively to better readability and understandability as a concrete state focussed only one level of if-statements, is isolated from other states (other isolated if statements) and encapsulated. Your internal stack is less loaded to see and understand the movable parts within the state than an equivalent nested If-then-else cascade.

What you do with this is applying the single responsibility principle. A state is responsible to only decide to which state to go next residing in one level of abstraction that definitely is affecting readability.

References

Oracle for example provide state machine like diagrams to define the syntax of their SQL variant:

SELECT (Oracle)

Another representation but effectively the same purpose PostgresSQL Documentation is following within the synopsis:

SELECT (Postgres)

Another way to formalize the syntax in a developers style is using the UML notations for a state chart:

UML state machine

The base theory for all of this are:

Petri nets

A very simple schema to get an idea how to implement it I provided here:

Infix to Postfix Formula Parser Java

#If vs switch If-statements and switch-statements are both "selections" (control structure). Selections produce abstractions in the control flow as you loose the information "which way was selected" afterwards.

Using one or the other does not change the control flow. So after all both are either good or evil or anything beneath it. Depending on the programming language they may be different in the assertions they give when mapping a datastructure to a control flow. But if you know that a switch statement serves the same purpose as an if statement readability becomes a matter of habituation and subjectivity. That is why I say also "switch" when I say "if".

You may have new syntactical sugar to express "selections" that will be more compact but it remains a selection.

#Abstraction The only interesting thing we are able to change to a more flexible structure is the abstraction that will be represented as abstract classes or interfaces with their concrete implementations. If you make proper decisions for abstractions they become beneficial (e.g. readability).

#Parsing A combination of the interpreter pattern and the state pattern will provide a solid structure for parsing things from various sources. The state pattern will guide your control flow through different compilation units that can be independently arranged. The interpreter will gather the instructions from the "state machine" and executes whatever it should do.

To be fair: You will finally not have less if-statements and a lot more compilation units. But you will have a beneficial structure that decouples nested if-statements in an elegant way to be able to recompose the control flow. So you will get the flexibility to meet future parsing requirements when extending the interpreted language.

Here we have a beneficial structure that leads objectively to better readability and understandability as a concrete state focussed only one level of if-statements, is isolated from other states (other isolated if statements) and encapsulated. Your internal stack is less loaded to see and understand the movable parts within the state than an equivalent nested If-then-else cascade.

What you do with this is applying the single responsibility principle. A state is responsible to only decide to which state to go next residing in one level of abstraction that definitely is affecting readability.

#References Oracle for example provide state machine like diagrams to define the syntax of their SQL variant:

SELECT (Oracle)

Another representation but effectively the same purpose PostgresSQL Documentation is following within the synopsis:

SELECT (Postgres)

Another way to formalize the syntax in a developers style is using the UML notations for a state chart:

UML state machine

The base theory for all of this are:

Petri nets

A very simple schema to get an idea how to implement it I provided here:

Infix to Postfix Formula Parser Java

#If vs switch If-statements and switch-statements are both "selections" (control structure). Selections produce abstractions in the control flow as you loose the information "which way was selected" afterwards.

Using one or the other does not change the control flow. So after all both are either good or evil or anything beneath it. Depending on the programming language they may be different in the assertions they give when mapping a datastructure to a control flow. But if you know that a switch statement serves the same purpose as an if statement readability becomes a matter of habituation and subjectivity. That is why I say also "switch" when I say "if".

You may have new syntactical sugar to express "selections" that will be more compact but it remains a selection.

#Abstraction The only interesting thing we are able to change to a more flexible structure is the abstraction that will be represented as abstract classes or interfaces with their concrete implementations. If you make proper decisions for abstractions they become beneficial (e.g. readability).

#Parsing A combination of the interpreter pattern and the state pattern will provide a solid structure for parsing things from various sources. The state pattern will guide your control flow through different compilation units that can be independently arranged. The interpreter will gather the instructions from the "state machine" and executes whatever it should do.

To be fair: You will finally not have less if-statements and a lot more compilation units. But you will have a beneficial structure that decouples nested if-statements in an elegant way to be able to recompose the control flow. So you will get the flexibility to meet future parsing requirements when extending the interpreted language.

Here we have a beneficial structure that leads objectively to better readability and understandability as a concrete state focussed only one level of if-statements, is isolated from other states (other isolated if statements) and encapsulated. Your internal stack is less loaded to see and understand the movable parts within the state than an equivalent nested If-then-else cascade.

What you do with this is applying the single responsibility principle. A state is responsible to only decide to which state to go next residing in one level of abstraction that definitely is affecting readability.

#References Oracle for example provide state machine like diagrams to define the syntax of their SQL variant:

SELECT (Oracle)

Another representation but effectively the same purpose PostgresSQL Documentation is following within the synopsis:

SELECT (Postgres)

Another way to formalize the syntax in a developers style is using the UML notations for a state chart:

UML state machine

The base theory for all of this are:

Petri nets

A very simple schema to get an idea how to implement it I provided here:

Infix to Postfix Formula Parser Java

#If vs switch If-statements and switch-statements are both "selections" (control structure). Selections produce abstractions in the control flow as you loose the information "which way was selected" afterwards.

Using one or the other does not change the control flow. So after all both are either good or evil or anything beneath it. Depending on the programming language they may be different in the assertions they give when mapping a datastructure to a control flow. But if you know that a switch statement serves the same purpose as an if statement readability becomes a matter of habituation and subjectivity. That is why I say also "switch" when I say "if".

You may have new syntactical sugar to express "selections" that will be more compact but it remains a selection.

#Abstraction The only interesting thing we are able to change to a more flexible structure is the abstraction that will be represented as abstract classes or interfaces with their concrete implementations. If you make proper decisions for abstractions they become beneficial (e.g. readability).

#Parsing A combination of the interpreter pattern and the state pattern will provide a solid structure for parsing things from various sources. The state pattern will guide your control flow through different compilation units that can be independently arranged. The interpreter will gather the instructions from the "state machine" and executes whatever it should do.

You will finally not have less if-statements. But you will have a beneficial structure that decouples nested if-statements in an elegant way to be able to recompose the control flow. So you will get the flexibility to meet future parsing requirements when extending the interpreted language.

Here we have a beneficial structure that leads objectively to better readability and understandability as a concrete state focussed only one level of if-statements, is isolated from other states (other isolated if statements) and encapsulated. Your internal stack is less loaded to see and understand the movable parts within the state than an equivalent nested If-then-else cascade.

What you do with this is applying the single responsibility principle. A state is responsible to only decide to which state to go next residing in one level of abstraction that definitely is affecting readability.

#If vs switch If-statements and switch-statements are both "selections" (control structure). Selections produce abstractions in the control flow as you loose the information "which way was selected" afterwards.

Using one or the other does not change the control flow. So after all both are either good or evil or anything beneath it. Depending on the programming language they may be different in the assertions they give when mapping a datastructure to a control flow. But if you know that a switch statement serves the same purpose as an if statement readability becomes a matter of habituation and subjectivity. That is why I say also "switch" when I say "if".

You may have new syntactical sugar to express "selections" that will be more compact but it remains a selection.

#Abstraction The only interesting thing we are able to change to a more flexible structure is the abstraction that will be represented as abstract classes or interfaces with their concrete implementations. If you make proper decisions for abstractions they become beneficial (e.g. readability).

#Parsing A combination of the interpreter pattern and the state pattern will provide a solid structure for parsing things from various sources. The state pattern will guide your control flow through different compilation units that can be independently arranged. The interpreter will gather the instructions from the "state machine" and executes whatever it should do.

To be fair: You will finally not have less if-statements and a lot more compilation units. But you will have a beneficial structure that decouples nested if-statements in an elegant way to be able to recompose the control flow. So you will get the flexibility to meet future parsing requirements when extending the interpreted language.

Here we have a beneficial structure that leads objectively to better readability and understandability as a concrete state focussed only one level of if-statements, is isolated from other states (other isolated if statements) and encapsulated. Your internal stack is less loaded to see and understand the movable parts within the state than an equivalent nested If-then-else cascade.

What you do with this is applying the single responsibility principle. A state is responsible to only decide to which state to go next residing in one level of abstraction that definitely is affecting readability.

#References Oracle for example provide state machine like diagrams to define the syntax of their SQL variant:

SELECT (Oracle)

Another representation but effectively the same purpose PostgresSQL Documentation is following within the synopsis:

SELECT (Postgres)

Another way to formalize the syntax in a developers style is using the UML notations for a state chart:

UML state machine

The base theory for all of this are:

Petri nets

A very simple schema to get an idea how to implement it I provided here:

Infix to Postfix Formula Parser Java