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

Denormalize

[tomhath]

I won't even call it a "bad programming idea". I've seen more problems from over normalizing a database than from under normalizing.

Maybe the bad idea is trying for fourth normal.

Re:Denormalize

[sexconker]

CNF2 is good. CNF3 is sometimes better. CNF4 is usually worse.

Re:Denormalize

[Anonymous Coward]

If it is stupid and it works, it is not stupid.

I learned the above in the military, and I have seen no reason to unlearn it in 32 years working as an IT professional... Yeah, I'm no longer a programmer, but I still reach for my favorite hammer when I see a nail. Two years ago, I embedded Assembly Code into something that operated on Terabytes of transaction data. It wasn't stupid.

Re:Denormalize

[SpaghettiPattern]

CNF2 is good. CNF3 is sometimes better. CNF4 is usually worse.

Sorta. First you analyze your model to be 3NF or 4NF. Then you denormalize in a controlled way. Logic before optimization.

Accidental 2NF usually means the problem wasn't well analyzed. And that most likely there will be problems ahead caused by bad abstraction.

pop

[Anonymous Coward]

using assembly language to code a web page because the boss wanted it to be fast

Goto

[jomegat]

Goto. I use that (in C) for error handling all the time, and frankly, it is about the cleanest way to do it I have seen.

Re:Goto

[fahrbot-bot]

Goto. I use that (in C) for error handling all the time, and frankly, it is about the cleanest way to do it I have seen.

One little goto. How bad can it be?

HTML

[Anonymous Coward]

While it's great for reporting, It will never be a good fit for real applications. When I say real, I mean the ones that you use to actually get work done and not browse kitten videos. Modern use of HTML/JavaScript is the worst example of shoving a square peg into a round hole that I've ever seen... and yet, with enough effort, we make it work.

Bad Ideas

[MightyMartian]

Coding in Javascript, PHP and VB6.

Magic Numbers!

[BarneyGuarder]

Magic numbers save tons of time. You get to working code quickly to verify your algorithm. They nev

>Segmentation Fault

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:Shying away from OOP(s)

[dgatwood]

Likewise. OOP is an interesting design pattern, but not when taken to the extreme. Far too often, people use inheritance where an "if" statement in a couple of methods and an initialization-time flag would have sufficed, and the result is invariably unholy.

I don't agree, however, that functional programming is an improvement. Functional programming is a migraine. In my experience, it usually causes things that are relatively trivial in procedural programming to turn into mounds of code. Everything that's bad about OOP is also bad about FP, just in different ways.

The goal should always be to produce less code, to the maximum extent possible, and both of these paradigms tend to do the opposite—particularly in the hands of beginners, but not exclusively so.

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.