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.

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

[lordlod]

Sure, C gotos are the cleanest solution in a few specific cases and sometimes I get frustrated in higher level languages that lack it.

However I still demonise gotos when teaching coding because it should be use carefully and sparingly. New programmers often see it as a versatile stick that can solve all their problems, and while it can make the code "work" we moved on from spaghetti code for a reason.

My personal rule is that a goto should only ever go down the code and never into new blocks.
(except for implementing a try/catch system using longjump, every rule has an exception...)

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.

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.

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

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.

Empty set

[Excelcia]

There aren't any bad programming ideas that work.

Re:Empty set

[internerdj]

Most bad programming ideas are bad programming ideas because they don't scale. They work fine in a small code base with sufficient documentation. They probably work fine sparingly in a large code base with good documentation. The problem is that if we teach bad programming ideas are routinely OK if we are careful, then we rely on them and when scope grows and we inevitably hit a moment in the project that doesn't allow for solid adherence to good software engineering practices then it blows up in our face spectacularly.

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.

enum values

[Anonymous Coward]

I've occasionally relied on enumerations being particular values, as a shortcut. Makes me feel icky, tho.

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)

[quietwalker]

I had to work under a lead who had "Design Pattern Prejudice". Every class had to be named based on the pattern it took after, and everything had to come from factory factories that worked off interfaces to abstract parents at every step, everything had to be immutable, and in any given review, he'd point to a section of code and ask what design pattern this followed. If you couldn't specify one, he'd fail the review, and if you could, he'd want you to rewrite it to use at least 2 or 3 more patterns.

Granted, he'd spend a whole week writing code, fail to complete any of his issues, and check in around 40 new classes & interfaces, but not one of them had any business logic in them at all, and then demand everyone refactor their code to use his new architecture.

We only got things done when we started ignoring him.

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)

[Dutch Gun]

It could definitely be an anti-pattern if used incorrectly, but honestly, I've been programming in C++ for about twenty years, and do you know how many times I've seen co-workers abuse operator overloading? Precisely ZERO. Seriously... never seen it. Apparently, I work with people who weren't stupid to flagrantly abuse operator overloading for no good reason, even among those who didn't exactly produce the cleanest or more elegant code.

On the other hand, this is the type of code I typically work with:

Vector3 posDelta = position - lastPosition;

Or this:

Matrix m = m1 * m2;

Overloading operators is best done in an absolutely literal sense. For instance, if you're doing matrix multiplication or subtracting two positions to get a delta value, the intent and what's happening in the code is 100% clear to everyone.

I chuckle sometimes at how C programmers believe that there's some evil overloaded operator lurking behind every multiply or addition. Uh, yeah... you can also obfuscate the crap out of your C programs too (pretty sure I've heard about some sort of contest too *cough*), but you just don't do that.

Re:Shying away from OOP(s)

[Alomex]

Some of us are old enough to have gone through a generation of "overload everything" which was a disaster.

Only much later did people learned to use overloading sparsely and with good effects.

This is similar to OOP which is also overused. Heck in Java you can't even have a variable or a function living on its own. Everything must be an object (except native types, sometimes).

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.

Magic Numbers!

[BarneyGuarder]

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

>Segmentation Fault

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.

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.

PHP

[EmperorOfCanada]

People crap on that language and, when I use it I usually violate MVC hard enough that it needs therapy. Yet, damn, I can pound out high quality products in that format like I am a programming firehose. I am talking products that make money and need little to no maintenance for years to come.

I can do python flask stuff that is technically cleaner, I could even do something super hardcore like a C++ we back end but for the easy homerun, PHP it be.

Obviously I am talking about the web.

Another dirty secret is that I do most of my stuff from scratch. Nearly every framework or great IDE extra out there I ignore. The whole storyboards thing in iOS, nope, Java on Android, nope, or just about any proprietary system that tells me how I should do something is a big fat nope. I find with most huge frameworks that I can knock of an almost fully functional prototype in no time at all, but then I start fighting with the framework and can never finish, 90% done and that is it.

By working with the fundamentals and good libraries, I start slow, and finish slow, but finish I do.

Duff's Device

[hmckee]

Seriously, the first time I saw Duff's Device I really thought it was a mistake. It's a do/while intermingled with a case statement. Look it up and be amazed.

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.