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

[Anonymous Coward]

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

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?

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

[xevioso]

Applications? HTML was never meant for "applications". It was meant for web *pages*. Websites.

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:

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

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.

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)

[Shados]

I came here to actually say OOP.

Its an absolutely terrible idea that tries to make software work the way we think it should, not the way we think.

It never ends well, and every time it goes to hell, people say "Oh, but if it had been done right in the first place..."

Though somehow people actually make it work, and right now superior functional patterns aren't taught, so if you implement them everyone thinks you're crazy. So for now, OOP is a terrible idea that "works", that many know is wrong, but that we still use for historical reason to make working software, for now.

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)

[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)

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

Good enough that people won't stop doing it...

[Narcocide]

... despite that I keep telling them not to, but never good enough to save their business plan or their company from disregarding my wisdom.

  - Agile/scrum, anything related to it, inspired by it, or even remotely like it, and the mindset of managers who advocate it.

  - "continuous integration"

  - "devops"

  - server-side javascript

  - giving every single person in the IT department the root server access

  - using microsoft "solutions"

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.

Re:Multiple Returns

[phantomfive]

I stopped doing that one day when I looked at the disassembly of my function and realized the compiler was optimizing my code to have multiple returns.

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

Re:MUMPS

[phantomfive]

Here is an example of some clear, easy to read, written-to-the-highest-standard MUMPS code for your inspection.

Magic Numbers!

[BarneyGuarder]

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

>Segmentation Fault

Re:Put the business logic in the database

[guruevi]

Bad programming ideas: separating "business logic" from the rest of your program. Not sure what the difference is between 'business logic' and the rest of your programs that run your business but a lot of people seem to want to separate them out.
Any database implements a turing complete language, it's generally a really bad idea to do anything there. Although to save time, I've often implemented SQL triggers and the like to do clean up that I didn't want to figure out in the program.

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.

Javascript

[Snotnose]

In 40 years I've used dozens of languages, the only one I learned to actively hate was Javascript/ECMAscript. A pathetic, piss poor excuse for a language.

I've heard PHP is just as bad but, as I've never written anything in PHP I'll give it the benefit of the doubt.

Objective-C

[hcs_$reboot]

Objective-C and its weird syntax reached success within the iOS world

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.

Re: Bad programming idea that works

[bluefoxlucid]

Depends on the utilization patterns.

Heavy I/O utilization will give you a bad time. As a counter-point, overprovisioning RAM relative to your working set will cut back on some of the I/O--a lot, if you're not on a write-heavy workload or a database. Correct RAM provisioning has to include the working set (application memory) and page cache (which is working set represented on disk, rather than persistently loaded into memory by the application).

PU utilization at 90% during peak is fine, if your applications can handle it. A PHP or C# application that can service 5,000 requests per second only takes, on average, 1/5000th of a second to fully-service a request; if it's designed to queue and thread in some sane way, then it shouldn't stall later requests because an earlier request is waiting for something. Its ability to handle 5,000 requests per second includes all that overhead: you can't automatically scale the HW requirements to service 100 RPS and claim now it does 5,000.

An nginx server at 90% utilization typically operates just fine, because nginx (as a reverse proxy, caching proxy, or static file web server) *does* serialize sanely. It provides one worker per CPU (configurable), and passes requests to workers under the least load. Each worker serializes requests--they service one request at a time--and will basically put a waiting request on hold and immediately start servicing a different request. If a worker is waiting with no request to service, it can take a new request--even if it has 37 requests all waiting for something (I/O, a back-end proxy, an application).

Writing an application to handle parallel requests with that kind of efficiency is *hard*. It's not impossible, and some applications handle it well; others do in fact increase latency significantly with utilization.

Latency will, of course, always increase when utilization exceeds unity. Using more than 100% of all CPUs means something has to wait.

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.

Dear Square Peg

[PortHaven]

From Round Hole,

Please go look at some old houses and barns. Guess what, the construction is almost all "post and beam"...and guess what, they did it by hammering square pegs into round holes.

Why?

Because it is very hard to drill a square hole. And making round pegs is far more labor intensive than square ones, and wastes a ton of wood. Lasty, friction baby.....that's right. A round peg in a round hole will either slide in and out too easily and not be secure OR it will be so tight that the friction will make it nearly impossible to fit it in. So instead, they hammers a square peg into a round hole. Both the peg and the hole deformed slightly. Allowing for a tightly fitted peg to lock the post and beam together.