Learn about temporal logic and how switch and if-then-else statements tend to be overused in code.<\/b>
\nJoin the DZone community and get the full member experience. In computer science, there is nothing more fundamental and intuitive than control structures. Every student learned about them in the first few weeks of any computer science program. We could not code without them, period. But they are not set in stone: we did get rid of the infamous GOTO in the 80s! At the pre-ALGOL meeting held in 1959 Heinz Zemanek explicitly threw doubt on the necessity for GOTO statements; at the time no one paid attention to his remark, including Edsger W. Dijkstra, who later became the iconic opponent of GOTO. [3] The 1970s and 1980s saw a decline in the use of GOTO statements in favor of the \u00a0\u00bb structured programming \u00a0\u00bb paradigm, with goto criticized as leading to \u00ab\u00a0unmaintainable spaghetti code \u00a0\u00bb And this paper is far from being the first call for using less conditional flows in programming. Even Uncle Bob has tackled the topic. In npm alone, countless packages have been published to provide an alternative. People tend to think that the catch with switch and if-then-else is that the more branches in your code, the more opportunities for untested and unexpected behavior. Every branch requires different use cases to be tested thoroughly, and even though, some tools, such as Istanbul, provide some indication as to how many branches have been executed, in addition to the traditional function coverages. But branches are part of the nature of programming, there is nothing we can do about it. In this short opinion brief, I would like to give a new spin on when to use control structures and when to use some functional alternatives. Ever since I discovered Dr. Lamport’s Temporal Logic of Actions, my programming style has changed to become more explicit about assignments vs mutations of the application state, and more conscious about temporal logic. For me, there are three core patterns to programming: Object-Oriented Programming, Functional Programming, and Temporal Programming. A developer should master all three and use them accordingly, no one pattern wins over the other. We cannot write good programs with one pattern only. One of the key notions of Temporal Programming is control state: when the light is off, and If the switch is in the off position, I can turn the light on otherwise check the circuit breaker (in bold we have the actions that are expected in a given control state). These are extremely familiar concepts we use every day, yet for some reason, we rarely make the control state explicit in the code we write. My take on it is that situation came about from a lack of alternative constructs, and the ease of use of switch and if-then-else, over the rigor needed to use temporal programming constructs, but that discussion is for another article. I’d like to focus here on something much simpler and actionable today. First, we must absolutely stop using these control structures for (complex) assignments, it often leads to some pretty ugly code that is hard to read and debug. How many times have you written some code like this? come on, tell me in the comments… How about a functional alternative? My code is not new, it is actually heavily inspired by that article from Hajime Yamasaki Vukelic, which probably got inspired by many similar articles. I brushed up his code to make it a bit more developer-friendly and implement some automatic behavior. We can now rewrite the code above in a functional way and do a proper assignment. As a side note, my programming style uses named predicates such as exists, rather than writing inline condition functions. It makes the code a lot more readable, maintainable and testable for complex predicates (imagine a bug in a complex condition…). The matchReduce function composes an array of functions conditionally. That may well be related to monads, but I have no idea since, to this day, I am still looking for a clear definition of what a monad is. You can find some code examples on how to use match and matchReduce here. Now we could stop here and say, alright, for all assignments I’ll use this functional construct, and if you did that, that article would have achieved already a tremendous transformation. That would mean that: Imagine the benefits of just adopting that approach! If you don’t write to me in a year, in ten years, and… when you retire, to tell me how much this programming style changed the course of your work, I would not believe it. Now if you want to learn about Temporal Programming and be more explicit about control state while continuing your journey to stop using switch and if-then-else, I developed a couple of npm packages: sam-pattern, and sam-fsm. I will write a full article on how to use the SAM pattern and those two packages soon. In the meantime, happy coding! Opinions expressed by DZone contributors are their own.<\/p>\n