Sometimes one ends up doing functional programming without being aware of it. Having entered that space, it’s easy to fall into complex logic traps that can be difficult to work through.
As an example, lets consider a Windows MSI installation script. Nearing the end of the install process the MSI “InstallFinalize” command is executed. An installer script may then have many “custom actions” that follow. These actions typically have conditions that govern execution.
For example, there may be need to restore prior settings if this is an upgrade. Or there may be a need to install default templates and so on.
What can happen over time is that custom action A is created, then B, C… ‘A’ may be for for an upgrade, ‘B’ for new install, ‘C’ for a new install of version 10.1 templates… I’ve seen conditions such as:
NOT INSTALLED AND &SERVER=3 OR REMOVE<>”ALL” AND &SERVER=3 AND OLDPRODUCTS
or in other words: C1 & C2 | C3 &C2 & C4
This is an actual condition set, probably not well done.
Also, I’ve seen action ‘D’ with condition C1 immediately followed by action ‘E’ with the same condition. Or action ‘F’ with a non-matching condition between ‘D’ & ‘E’.
When this collection of actions & conditions approaches about a dozen, it’s very easy to get lost. This is clearly technical debt that needs refactoring. When a series of actions are called with the same conditions, consolidating into one action reduces opportunities for error.
If you’re using an installer authoring tool such as InstallShield, there may be out-of-the box custom actions that are small & focused. If one isn’t careful, the installer can end up with several calls to custom action X with conditions to match each install use case. Now add many more custom actions with the same condition set and you’ll end up in this quagmire.
I don’t think it makes sense to offer a solution; rather be aware of the overall long-term direction.