My advice: do nothing for this code without a clear business code to make changes.
Your code is clear, obvious, probably correct, easy to maintain, and easy to debug. Why don't you change it in any way ? Spend your time adding value by fixing bugs and adding features, rather than changing your working code unnecessarily. When your boss asks you, "So what did you do today?" the answer should not be "I increased the risk of the schedule by making unnecessary cosmetic changes to fix, work, already debugged code."
Now, if the problem really exists, the problem is probably not that the code is hard to read, but rather that the code is hard-coded for what should be a user-configurable business process. In this case, create an object called "Workflow" that encodes the business process, and an engine that evaluates an arbitrary workflow. Then create an instance of this object that represents the desired workflow based on input from the user.
This actually adds value to the user; the user cares a bit about whether you use nested if statements or not.
source share