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

[Derekloffin]

Yeah, that. It is often a real pain in the neck to deal with a heavily normalized DB, where a few simple pieces of denormalized data would help you out immensely. "Bad" idea, but definitely works at times.

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.

Re:Goto

[Darinbob]

I've seen code that avoids this, or avoids multiple returns from a function, and the result was very difficult to understand. Either lots of misc state variables, or extreme indentation, etc.

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.

Re:HTML

[glenebob]

Yeah, I think that's the point. We've managed to take something meant for web pages and figured out how to embed fucking operating systems into it.

Bad, you want bad:

[geoskd]

C++ Template Metaprogramming FTW.

For when it absolutely positively has to squeeze every last instruction cycle, and screw the next guy...

Empty set

[Excelcia]

There aren't any bad programming ideas that work.

Bad Ideas

[MightyMartian]

Coding in Javascript, PHP and VB6.

Re:Bad Ideas

[ZecretZquirrel]

Specifically, so-called "web" interface programming using client-side Javascript on the DOM.

Using !important in css

[xevioso]

There's a lot of cases where you end up doing something that is considered not "best practice" and is frowned upon, but it gets the job done, is not likely to cause headaches for future developers, and is the most efficient way to solve a problem. It's not programming, but using !important to force a style when you absolutely have to or to override a bad implementation of bootstrap is a surefire way to solve an issue.

Shying away from OOP(s)

[shellster_dude]

Few programs are more hellacious to write and maintain than code that has been overly-factored into classes, that inherit from other class, that implement some abstract that was inherited from other abstract, that isn't even called directly because it is actually a event handler or intent for yet another inheritance mess. OOP makes sense if used sparingly, if not, it makes GOTO spaghetti look sane.

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

[geoskd]

The goal should always be to produce less code

Absolutely not, the goal should be to write the simplest code. Simplest being defined as easiest to understand that gets the job done. Simple code has fewer bugs, is generally easier to write, even if it is longer sometimes, and is far and gone easier to maintain.

Many code abbreviation techniques actually make code harder to understand, like some of the sketchier if constructs in C, in-line class definitions in C++, etc... And before you start talking about in-line class definitions being faster, modern compilers have been able to handle whole program optimization including cross-source in-lining for many years now, there is no longer any benefit to having any code in headers, and for readability, lots of good reasons to never have code in headers. Keep each class in its own files (header and source pair), and nobody gets hurt.

Re:Javascript

[grcumb]

Javascript, the worst possible programming idea that seems to unfortunately work.

Son, you only say that because you've never poked the Cold Fusion bear. In earlier versions, it didn't even have subroutines.

Views are extremely helpful in such cases

[raymorris]

Views allow you to operate on the database as if it were denormalized, without losing the consistency guarantees and other benefits of a properly normalized database.

It's the same concept as STORING datetimes as a number internally, a consistent, monotically increasing number, while DISPLAYING them as strings like "November 6, 2016 1:30 AM". Storing "November 6, 2016 1:30 AM" is crap for any kind of calculation, especially because that string represents two different times an hour apart - there's no way to know whether that comes before or after "November 6, 2016 1:20 AM".

Similarly, views are virtual tables which provide whatever you'd like the user to see, without breaking the underlying data structure.