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.

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.

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.

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.