Ask Slashdot: What Are Some Bad Programming Ideas That Work? (infoworld.com)

snydeq writes: Cheaper, faster, better side effects -- sometimes a bad idea in programming is better than just good enough, writes InfoWorld's Peter Wayner: "Some ideas, schemes, or architectures may truly stink, but they may also be the best choice for your project. They may be cheaper or faster, or maybe it's too hard to do things the right way. In other words, sometimes bad is simply good enough. There are also occasions when a bad idea comes with a silver lining. It may not be the best approach, but it has such good side-effects that it's the way to go. If we're stuck going down a suboptimal path to programming hell, we might as well make the most of whatever gems may be buried there." What bad programming ideas have you found useful enough to make work in your projects? Don't be shy or ashamed, we all want to hear your responses!

Comments

Switch(true)

[omnichad]

switch(true) {

      case $a < 5:

      do something;

      break;
...

}

A bit messy, but a lot cleaner than a stack of if/then/else for a set of of conditions.

Re:Bad, you want bad:

[geoskd]

And tbh it's not that efficient anyway, but the programmer who wrote it doesn't know because he didn't time it........

Yes it is, and yes we do. Our programs run against massive data sets (anywhere from a couple hundred MB to tens of TB) on a single machine. Our inner loops run billions of iterations per pass, and response time is absolutely critical. A single extra instruction in an inner loop can cost many seconds of real response time. Cloud solutions are not an option, and neither are large server farms. This thing has to run on somebodies desk.

Short of assembler, there are not many ways to improve on what we are doing, and even there GCC and MSVC++ both produce some damn fast and highly efficient code when fed the right diet of templated inline functions. In the few cases where the final assembled version has made me do a WTF, it turned out to be instruction re-ordering to take advantage of (or work around) quirks of the x86 machines in common use today. I have been very hard pressed to beat the compiler for most functions compiled from good TMP. Some of the things we do with it simply cant be done anywhere else but assembler. Even C has its limitations.

As an exercise, try to figure out how to get a C program to compile down to a dynamic set of functions, all in-lined into a single function. In TMP, I can do it. The templating spreads out the function into as many versions as it takes to cover all the possible variations, each of which is a fully in-lined version containing only the desired "calls". I have been programming in C a long time, and the best I have ever seen was someone try to implement the same thing by actually implementing all the different variations of the in-lined function by hand, and then creating a jump table to pick the right one. It was thousands of LOC and prone to typos, as opposed to the TMP version which was 50 LOC, and either worked or didn't, no place for small corner case errors to hide.