Hilarious Programming Jargon Phrases You Need to be Aware Of

As programming is a living mechanism, programming jargon is growing bigger and changing, which means it is a living mechanism too.

Co-founder of Stack Exchange, Jeff Atwood, has a huge list of 30 new pieces of programming jargon that have emerged on the question-answer site of his.

As you might guess, they are hilarious phrases.

I’ve tried to combine some of them here in my post, but can check out th e full list on his blog, Coding Horror.

Yoda Conditions: When a programmer writes the conditions for a piece of code in the opposite order for which you would expect to normally read them. (Instead of saying if(variable == constant), the code says if(constant == variable).)
Smug Report: A bug report submitted by a user who thinks he or she knows everything about a system, when he or she does not.

Egyptian Brackets: You know the style of brackets where the opening brace goes on the end of the current line, e.g. this?

if (a == b) {
    printf("hello");
}

We used to refer to this style of brackets as "Egyptian brackets". Why? Compare the position of the brackets with the hands in the picture. (This style of brackets is used in Kernighan and Ritchie's book The C Programming Language, so it's known by many as K&R style.)

A duck: A feature added for the sole purpose of drawing attention to itself from management to be removed, avoiding unnecessary other changes in a product.
Refuctoring: Taking a well-designed piece of code and, through a small series of changes, making it completely unmaintainable for anyone other than yourself.
Heisenbug: A play on "Heisenberg," a principle in quantum mechanics, a Heisenbug is a bug that disappears or alters its characteristics when an attempt is made to study it.
Jimmy: A generalized name for a clueless or new developer.

Higgs Bugson: Another bug based on a physics phenomenon, a Higgs Bugson is a bug that's hypothetically predicted to exist based on other conditions, but is difficult to produce.
Unicorny: A feature so early in its planning stages that it might as well be imaginary.
Hindenbug: A catastrophic, data-destroying bug.

Fear-driven development: When project management adds more pressure, such as by firing engineers.
Hydra: A bug that, when an attempt to fix is made, introduces two new bugs. It's a bug that cannot be fixed.
Baklava Code

Code with too many layers.

Baklava is a delicious pastry made with many paper-thin layers of phyllo dough. While thin layers are fine for a pastry, thin software layers don’t add much value, especially when you have many such layers piled on each other. Each layer has to be pushed onto your mental stack as you dive into the code. Furthermore, the layers of phyllo dough are permeable, allowing the honey to soak through. But software abstractions are best when they don’t leak. When you pile layer on top of layer in software, the layers are bound to leak.

Common Law Feature: A bug that has existed for so long that it is considered a feature.
Loch Ness Monsterbug: A bug that has only been spotted by one person.
Rubberducking: Talking with other engineers to solve a problem.
Hydra Code: Code that cannot be fixed. Like the Hydra of Legend, every new fix introduces two new bugs. It should be rewritten.
Banana banana banana: Placeholder text in code that hasn't been implemented yet.
Reality 101 failure: Creating a program that does exactly what was asked, but the problem it's trying to solve was misunderstood and the program is basically useless.

Ninja Comments: Also known as invisible comments, secret comments, or no comments.
Mad girlfriend bug: When you see something strange is happening, but the software is telling you everything is fine.
Hooker code: Code that is problematic and causes application instability.
Jenga code: The whole program collapses once you alter a block of code.

More: Stack Overflow Progr