To the “down-voters” among you, who may mistake brevity for lack of wisdom or experience, I invite your reconsideration. Here’s why.
The “clever improvements” as suggested cause each of the various if cases to become coupled. In other words, as long as each and every if-case that could possibly be required, for the entire service lifetime of this application (which could be a decade or more), is identical ... the code is “clever,” and perhaps it may look a wee bit more agreeable to the digestion.
However ...
Change will come. Some day, a condition will need to be added that will break the rule. And, when that happens, suddenly the code that is working properly now must be torn-apart, more or less, and recoded. What was meant to be clever has just turned bad, and it de-stabilized all of the logic that it “cleverly” tied together. Whereas, if the “ugly” if..elsif structure had simply been retained, no changes to any of the existing code, with its admittedly repetitive structure, would have been required. You would simply need to add another elsif block at the appropriate point. You can keep that up indefinitely.
Please bear in mind that I have spent most of my career in “code rescue” and project-turnarounds. Which means that my perspective on such things is somewhat like that of a coroner. Such “cleverness,” well-intentioned though it once may have been, after a surprisingly short amount of time attracts a large number of blowflies. Maintainability is king, and software must be designed in anticipation of a very long service life involving many different people. You won’t be at that job forever ... but your work will be, and someday I might be called in to have a look.
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
Given/When is syntactic sugar for if..elsif.
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |