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

[Anonymous Coward]

I also used to do this all the time in C. Code looks a lot cleaner this way.

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.

90% of "modern" software

[nadass]

Every new software, platform, framework, library, protocol, language, compiler... is rife with shortcuts (by design or accidentally) which are, relatively speaking, considered 'bad programming ideas' from generations of folks who did not prioritize them previously. So every modern program basically sucks for the same reason.

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.

Sub-optimal code.

[Derekloffin]

Frequently run into it, where I have a data set that is small, but difficult as hell code in such a manner as to go through efficiently. So, I can spend many hours trying to get the efficient code right, or just use the much simpler more brute force approach which will still get the task done just a quickly to the user's perception.

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...

Re:Bad, you want bad:

[phantomfive]

Yes it is, and yes we do.

Well, if you timed it, then you know.

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.

Working 80+ hour weeks

[Anonymous Coward]

Seems terrible because you become less productive, but with the overhead of communication with a larger team, it's still much more efficient than hiring more people.

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)

[hcs_$reboot]

Don't forget to include (C++) operator over-overloading.

Re:Shying away from OOP(s)

[Darinbob]

Bad programmers are bad programmers no matter what language or paradigm they use.

I think some of this arises from someone doing busy work and getting the feeling that they're making progress. Ie, create lots of classes, draw lots of lines between them, and it sort of looks like a design. Now you spend the next few months implementing the skeleton of all those classes, and then every time you go home it feels like you put in a good solid day at work, your boss looks at lines of code and you seem productive so you get a nice raise. If your fingers get sore from all that typing, then you just call a few meetings to start debating the merits of class naming, which patterns are missing that should be added, how to improve the whole process, and so on.

Re:Shying away from OOP(s)

[AuMatar]

I actually think you're completely backwards. Most programmers think in terms of basic OOP and procedural programming. Nobody thinks in terms of functional programming- that's why no functional language has ever been a major commercial language.

Re:Shying away from OOP(s)

[AuMatar]

Oh, got it. You're one of those people who just want to hear themselves talk and try to get the last word in rather than actually discuss things. I'll go back to ignoring you.

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.

Multiple Returns

[tomhath]

For a while the mantra was that you only return from a subroutine in one place, at the bottom.

I think that's been pretty much abandoned. Return when you're done; don't go through contortions to get out of nested loops or IF statements just so you can get to the return at the bottom.

Javascript

[Anonymous Coward]

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

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.

MUMPS

[mmell]

No, really - I'm not making this one up. MUMPS manages to find every possible bad coding idea and make it as easy as possible. Interpreted code, typeless data, naked array references, zero FS compatibility with anything . . .

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.