Categories
Uncategorized

New Programming Jargon

Every field comes up with its own jargon, and oftentimes subgroups within a field come up with their own specific words or phrases (those of you familiar with Microsoft Canada’s Developer and Platform Evangelism Team know that we have our own term for “broken”, named after one of our teammates who is notorious for killing all sorts of tech gear).

A question recently posted on Stack Overflow asked for people to submit programming terms that they or their team have coined and have come into regular use in their own circles. I took a number of the submissions and compiled them into the alphabetically ordered list below for your education and entertainment.

Have you come up with your own jargon? Tell us in the comments!

Banana Banana Banana

"Bluth's Frozen Banana" stand from "Arrested Development"

Placeholder text indicating that documentation is in progress or yet to be completed. Mostly used because FxCop complains when a public function lacks documentation.

Example:

/// <summary> /// banana banana banana /// </summary> public CustomerValidationResponse Validate(CustomerValidationRequest request, bool ...

Barack Obama

A project management account to which the most aspirational tickets – stuff you’d really like to do but will pobably never get approval for – gets assigned.

Bicrement

Adding 2 to a variable.

Bloombug

A bug that accidentally generates money. [Joey’s note: I have never written one of these.]

Bugfoot

Bigfoot

A bug that isn’t reproducible and has been sighted by only one person. See Loch Ness Monster Bug.

Chunky Salsa

A single critical error or bug that renders an entire system unusable, especially in a production environment.

Based on the chunky salsa rule from TVTropes: Any situation that would reduce a character’s head to the consistency of chunky salsa dip is fatal, regardless of other rules.

Configuration Programming / Programmer

Someone that says they are a programmer but only knows how to hack at configuration files of some other pieces of software configuration to make them do what they want.

Counterbug

A defensive move useful for code reviews. If someone reviewing your code presents you with a bug that’s your fault, you counter with a counterbug: a bug caused by the reviewer.

DOCTYPE Decoration

When web designers add a proper DOCTYPE declaration at the beginning of an HTML document, but then don’t bother to write valid markup for the rest of it.

Drug Report

A bug report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought have had one too many.

Duck

Rubber "Devil Duckies" surrounding a lone rubber "Angel Duckie"

A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.

This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.

The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.

Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “That looks great. Just one thing – get rid of the duck.”

Fear-Driven Development

When project management adds more pressure, such as by firing a member of the team.

Ghetto Code

Ceiling fan kludged by hanging a box fan from the ceiling

A particularly inelegant and obviously suboptimal section of code that still meets the requirements. [Joey’s note: I’ve written ghetto code before, but that’s because I’m street, yo!]

Hindenbug

A catastrophic data-destroying bug. Oh, the humanity!

Hocus Focus Problem

Unexpected behavior caused by changes in focus, or incorrect setting of focus. Could also be used to describe an app stealing your focus.

Hot Potato / Hot Potatoes

A fun way to pronounce http:// and https://.

IRQed

Annoyed by interruptions. Pronounced like and has a similar meaning to “irked”.

Jimmy

"Opie" from "Family Guy"

A generalized name for the clueless/new developer. The submitter at Stack Overflow writes:

We found as we were developing a framework component that required minimal knowledge of how it worked for the other developers. We would always phrase our questions as: “What if Jimmy forgets to update the attribute?”

This led to the term “Jimmy-proof” when referring to well designed framework code.

It’s probably best not to use this term around IronRuby developer Jimmy Schementi.

Loch Ness Monster Bug

A bug that isn’t reproducible and has been sighted by only one person. See Bugfoot.

Megamoth

MEGA MOnolithic meTHod. Usually stretches over two screens in height and often contained inside a God Object (an object that knows or does too much).

.NET Sandwich

When .NET code called native code which calls other .NET code and makes the poorly designed application crash.

n-gleton

A class that only allows a fixed number of instances of itself.

NOPping

Not napping, but simply zoning out. Comes from the assembly language instruction NOP, for No OPeration, which does nothing.

Pokemon Exception Handling

For when you just gotta catch ’em all!

Reality 101 Failure

Solar-powered flashlight

The program (or more likely feature of a program) does exactly what was asked for, but when it’s deployed it turns out that the problem was misunderstood and the program is basically useless.

Refuctoring

The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself. It’s job security!

The Sheath

The isolating interface between your team’s (good) code, and the brain-dead code contributed by some other group. The sheath prevents horrible things (badly named constants, incorrect types, etc.) in their code from infecting your code.

[Joey’s note: I’ve heard the term “shim” used for this sort of construct. I’ve used the term “transmogrifier” for this sort of thing.]

Shrug Report

A bug report with no error message or “how to reproduce” steps and only a vague description of the problem. Usually contains the phrase “doesn’t work.”

Smug Report

A bug report submitted by a user who thinks he knows a lot more about the system’s design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

Stringly-Typed

i can has string

A riff on strongly-typed. Used to describe an implementation that needlessly relies on strings when programmer- and refactor-friendly options are available.

Examples:

  • Method parameters that take strings when other more appropriate types should be used
  • On the occasion that a string is required in a method call (e.g. network service), the string is then passed and used throughout the rest of the call graph without first converting it to a more suitable internal representation (e.g. parse it and create an enum, then you have strong typing throughout the rest of your codebase)
  • Message passing without using typed messages etc.

Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.

Unicorny

An adjective to describe a feature that’s so early in the planning stages that it might as well be imaginary. This one comes from Rails Core Team member Yehuda Katz, who used it in his closing keynote at last year’s Windy City Rails to describe some of Rails’ upcoming features.

Yoda Conditions

Yoda: "if (5 == count)"

The act of using

if (constant == variable)

instead of

if (variable == constant)

It’s like saying “If blue is the sky”.

This article also appears in Canadian Developer Connection.

367 replies on “New Programming Jargon”

I’ve used the term “transmogrifier” for this sort of thing.

You’re not alone! I had used a map of “transmogrifier” functions with names like “dateMagick” and “arrayMagick” for shielding the new interface from the insanity of the legacy code.

I *love* the duck idea. I think that cops use this technique by writing up two violations at many traffic stops (or just threatening to) so that they can bargain away a bogus one in order to make the other one stick. I wish that I’d used the idea during past feature design. It certainly would have saved me a lot of grief.

I found a chunk of code in one of our legacy products where the guy was trying to start a process on another machine on the network so he stuffed some arguments into an array, print_r’ed it into a string buffer and emailed it to the other machine machine which received the email and reacted. i showed it to another developer and we laughed for hours. We affectionately refer to it as IPC via SMTP

If a user makes and stupid mistake, to tell them they made a ID-10-T error … lol … when the problem is between the chair and keyboard … idiot error (id10t error) ..

Spaghetti-code: A piece of software that is so chaoticly implemented that its inner design could best be described as a plate of spaghetti

“Yoda Conditions” are a good way to avoid problems with unvolonteer asignement in conditions.

Exemple :

Error :
if (constant = variable)
No error :
if (variable = constant)

I would laugh. But that would be not honest: this little article is almost like it saying a tale about my codes :D

btw, the Megamoth. i have a function that is 2174 line long. Should i call it Gigamoth? :D

I myself have coined the phrase “Code cancer” for code where a bad design descision or bad code has been left untreated. The result is code that increases exponentially with every feature added or bug solved (introducing more bugs in different scenario’s).
With true code cancer, the 500+ lines of offending code can be replaced with 50 lines of well designed, thought out code (true story).

NOTE:
“Yoda Conditions” are a good way to avoid problems with unvolonteer asignement in conditions.”

Or you use a compiler that can actually detect the difference between a boolean comparison and an assignment (C#), so you can continue to write code that is as natural as possible.

Another “great” approach to document classes or methods is “unCamelCasing” which is simply separating the camelcased words which make a class or method name and (optionally) re-ordering them and/or decorating them with some verbs, adjectives or useless filling words. It is most important that the result – no matter how short or long it gets – is telling the reader not a single bit more, than the class/method name already did.

Example:

IPersonSearchService
>> Person search service
>> Service for searching persons
>> Interface for person search service
>> This service is intended to be used by my beloved programming colleagues to perform the most complex and delicate actions such as searching persons from our mighty database

Oh I have one too!:
A paranoiac clearance distance.
It’s when you check for something that should never ever be possible..
Like:
a = 1;
If(a != 1) {
//Do this and that!
}

‘Deadline Driven Development’
When the amount of commits increases significantly the more you approach the deadline.

‘Highlander Pattern’
As a synonym for the singleton pattern. Because “There can only be one!”.

I am years out of my programming career (over which I sometimes sigh longingly), but one term comes to mind. I was a special resource programmer on a project on which we had inherited this really cool Indian guy, who was helping with the project development. We loved his accent. One day he was leaning over a team member and guiding him on some coding issues (some of the team were learning the code on the job). He commented that a piece of code was not needed, and referred to it as “monkey work”. From then on any superfluous job or piece of code became “monkey work”.

He also gave us the phrase “you/we are doomed” when he told that same consultant not code in a certain function. “If you do that we are doomed!” When he left the project, we were often heard saying, in a strong Indian accent, “Be careful, or we are doomed! Doomed I say!”

At our office, we refer to bugs as ‘undocumented features’. Works great as an excuse to the clients!

Sloppy-Paste: Copy/Paste some code and not checking if you’ve changed everything you needed to change.

Great assembly!
Let me add: “fear driven development” is a term, I have used in my country, Germany, too. Especially when people are not testing continously while deploying, but moving all parts of the process, they are afraid of, to a later date. Mostly this will be testing, integrating, deploying. In German, having fear, is also called “having shit”. So “shit driven development” is my favourite jargon!

Half Life Rule.
When the amount of work still to be done is halved but never seems to finish.

We use “poltergeist” to talk about seemingly illogical or incomprehensible errors with an origin that takes you hours to find out. Often evident when you finally find them.

“Kwantum” or “Flux” code
the exact opposite of the heisenbug, meaning that code runs perfectly unless you run the debugger or “look at the code”.

My favorite is Zombie code – dead code that is still executed and of course it usually sneaks up on you. Known to empty out weak minds.

Garbage-in = Garbage-out – I remember a story about crappy data. When a customer wanted us to do “data mining” to select all female customers 40 and older in a certain area.
My answer was: “50% of your customers don’t have a birthday. 10% are older than 90, 10% are younger than 16 (which is the age of your company), 10% have been born on January 1st 1970 and another 2% is going to be conceived some time next year. I could do something with other 18%, given I remove those that are marked as ‘female’ with the salutation code ‘Dear Sir’ (or vice versa).”
I guess crappy data is what you get for paying your call-center agents badly.

You need the Yoda conditions if you’re doing Java and might have null

“fred”.equals(some_nasty_null)

will be false

some_nasty_null.equals(“fred)

will throw null pointer exception.

(I don’t do Java any more, thank some random deity)

Featureslack.

Product with some features missing on purpose, only made worse because of these often being only trivial to implement.

Like how many (especially cable-company supplied) digital TV decoders NOT (..no longer..) allow the customer to reorder their channels.

In Domain Driven Design, “The Sheath” is referred to as an “Anti-Corruption Layer.”

Actually, I once heard that yoda conditions were used so that accidentally typing the assignment operator would cause an error instead of a silent behavioral failure.

I honestly don’t think it’s valid to make the code MORE unreadable by employing Yoda code to catch a “=” vs. a “==”. You should know fairly quickly what’s going on if you’ve done it wrong.

It just irks me that people continue to validate worthless crap like this. You’re not being pragmatic if you are shunning coding best practices.

http://stackoverflow.com/questions/4049746/coding-standard-for-null-checking

Further reading:
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

We had the term (rough translation): “Coat Commit”, when you already have your Coat on and ready to leave and then you commit and leave. Making the others suck with your bugs, or if you forgot to upload a file and such.
And the probably the less funny:
Dragon Drop -> Drag & Drop

Comments are closed.