I can definitely relate to the “temporary working solution”. Another corner I cut, although not to solve a particular problem, is using static a lot, because it’s quicker and easier, and I don’t seem to run into any problems.
Eww please never show me your code. If I have more than 3 uses of the static keyword in a small project it’s refactoring time for me.
I actually never cut corners. Or in other words, I don’t know any corners I can actually cut. Never occurred to me. Nope.
Unless you “define” corners for me. Once you’ve define a few, and you tell me this and that, I’ll first ask you for the reasoning behind all of these, and then ask you to tell me how to “cut” those corners.
I really don’t think you’re serious but still…
I came across the following words when I was teaching myself how to program C out of the Kernighan and Ritchie text: “C provides the infinitely-abusable goto statement, and labels to branch to. Formally, the goto is never necessary, and in practice it is almost always easy to write code without it. We have not used goto in this book” (65, 2nd Edition).
I never even looked at goto again after reading this, given that many regard K&R as the final word on all things C (so, naturally, I did too). Then, years later, I found myself writing very handy and functional nested loops that needed to exit out of multiple layers when a certain condition or conditions were met. I started wondering why the hell there isn’t a special version of break for this purpose. So to cope with this deficiency I would declare extra boolean variables to keep track of the nested loop’s execution state. It was only while reading about some of the more obscure features of Java that I rediscovered goto statements–called “labeled breaks”–and cursed myself (and K&R) for having written them off for so long.
As was previously mentioned, they can be incredibly useful and purposeful.