Hacking Coroutines into C

The intent here is nice. I historically hate state machines for sequential executioners. To me they make sense in FPGA/ASIC/circuits. In software, they just get so complicated. I've even seen state managers managing an abstracted state machine implementing a custom device to do what's ultimately very sequential work.

It's my same argument that there should be no maximum number of lines to a function. Sometimes, you just need to do a lot of work. I comment the code blocks, maybe with steps/parts, but there's no point in making a function that's only called in one place.

But anything is better than one person I met who somehow was programming without knowing how to define their own functions. Gross

I actually write a lot of Go in state machine like patterns. My state types files would make you think im schizophrenic. I just finished up a project this week that was 10k lines of comments in 18k loc. Noone else has to read it tho, they actually probably appreciate it if they did.

> there's no point in making a function that's only called in one place.

There's nothing wrong with doing that if it helps make your code clearer. The compiler's optimizer will inline it when appropriate so there's no runtime overhead either.

> I comment the code blocks, maybe with steps/parts, but there's no point in making a function that's only called in one place.

I encourage junior developers that get into this habit (getting worse now, with LLMs) to convert the comment into a function name and add the block as a function, thinking pretty carefully about its function signature. If you have a `typedef struct state` that gets passed around, great.

The reason for splitting up this code is so that the person writing it doesn't fuck up, the input/output is expressed as types and validated before they push it. It's easy for me to review, because I can understand small chunks of code better than big chunks, and logically divides up the high level architecture from the actual implementation so I can avoid reviewing the latter if I find trouble with the former. It's also good as a workflow, where you can pair to write out the high level flow and then split off to work on implementation internally. And most importantly, it makes it possible to test the code.

I have had this discussion with many grumbly developers that think of the above as a "skill issue." I don't really want to work with those people, because their code sucks.

Not only that, the compiler's optimizer might actually do a better job if you split up a big function. Because the smaller functions have less register pressure.

I think for me, and it sounds like for this author, the context lost by that abstraction makes it harder to review. In my experience it's easier for me to understand a small block of code, but it's harder to understand how it impacts the system when it's out of context.

For example:

x++;

A very easy piece of code to understand. But who wants x, and what values could they expect? Why do we ++ and under what conditions?

Those effects, again just for me your mileage may vary, tend to get much harder to understand.

I'm not sure I agree and I think you should try some stuff out on godbolt first. The compiler can see where variables are no longer in use, whereas unless you turn on link time optimization (which is known for being messy so nobody seems to), you'll likely get a lot of unnecessary push/pop between the function calls.