6v6gt:
Making one action, in this case sending an AT command to an external device, dependent on the results of a previous operation is quite a reasonable thing to do. If a failure is detected for example with the initialisation, then it is not useful to proceed to send the following commands.Neither do I believe that spaghetti code is a inevitable consequence of attempting to solve this. A state machine approach could provide an elegant solution here. If required, some of the state transitions could have a timing element to allow, for example, a serial buffer to fill.
That depends on how that dependency is coded. If it is weaved into deeply indented condition-dependent code then it will take more code than small tasks would to do the same thing. The bigger the job, the more extra it will take. I know this from experience and working my way out. When you take fixed contracts, you don't stick with the hard way.
State machines are good, they were part of the path up and out for me.
IPO tasking takes less code and may use state machines. It is a hell of a lot easier to add to.
Please note that the function I modified only works if called frequently during the time it runs. It maintains dependency but mainly not through indented structures though it does use indented structure.. being C code.