Don't do it right, double down on the flaws. You had a 3k SLOC single function (all in main) C program to do something that could be expressed cleanly and clearly in 200 SLOC. Some specific sequence of inputs leads to an error. Instead of tidying it up, removing the repetition that led to the mistake, you copy/paste everything again and add another 100 cases to your various switch/case statements (actually you use if/else because switch/case might make things clearer). The specific problem is solved, but in a year another buggy code path will be discovered and you'll have another chance to play hero. In 5 years it'll be 50k SLOC of C all in main, that could have been under 1k SLOC (still all in main). No one else will be able to fix it but you!
I kind of did that once. For a proprietary language that didn't support functions and had very limited support for loops (mostly labels and gotos, it is sold for way too much per seat for a niche industry and the language and implementation are awful). I needed to implement something that was too tedious to write out by hand (~1500 lines of this nonsense) so I made a Python program that spit out the code I needed.
The company that makes it also has a generator they use when they're contracted to make more code in their awful language. It's bad, the code has to be manually cleaned up and sometimes is delivered broken. Then they get the money on the support contract to fix their problems. (It's not their only product/service, but it's key to many of their services, a way of hooking customers.)
Their generator did not using the looping constructs, and several of their "senior" engineers actively discouraged it because "You can't be sure a loop will do what you want it to do." (Wish that weren't an actual quote.)
> "You can't be sure a loop will do what you want it to do."
From my limited experience with "proprietary bullshit languages that only exist to hook customers", there's ways to mess up how loops work in the language. So maybe those senior engineers actually know what they're talking about.
I've seen "languages" that treat variables differently based on whether they have uppercase letters and underscores. Before I saw this in action, I believed the seniors telling me to "never use uppercase letters ever" were insane...
Given the cost of the product, I considered all documented features fair game to use. If a bug was found because of a primitive looping construct, then they were on the hook to fix it (there weren't any, they worked fine). One of those same senior devs also didn't know basic logic rules like De Morgan's Laws and tried to "correct" my conditional logic and broke the program instead.
Not MUMPS, that one actually has a standard. This is a straight up proprietary, maintained-by-one-company language. The concept isn't bad (that is, the objective of having a way to automate a formerly manual, and lengthy, set of processes), but the implementation is. Market capture, that's the name of the game for that company. They slip this into all their projects so even if they lose a follow-on contract they still get license fees for their proprietary components.
