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”

Has anyone commented on the usefulness of the Yoda Condition?
Oh yeah, just about 80%!
People, please read the comments before posting your own.

Iment: Extra comment explaining what the previous comment really means

On Yoda comments… It’s about whether you prefer readability over clever tricks…

Yes, it is possible to make mistakes with comparisons vs. assignments, but I believe that as rule of thumb, programmers should strive for to write clear, readable, maintainable code. I.e. I like more English like code than Yoda conditions…

E.g. Pretty often you see very clever C-code that requires unnecessary mental strain to decipher…

I don’t like the Yoda condition.
It’s a pain to read so it’s a lost of time.
Those who lack self-confidence must use force :-)

How you call that ?
if ( variable == true ) instead of if ( variable )

yoda conditions in java avoid null checking:
if (s != null && s.equals(yodaConst))
become
if (yodaConst.equals(s))

So, go yoda, go!

Very similar to the Yoda conditions is the use of if (const.equals(var)), rather than if (var.equals(const)), (if (“http”.equals(protocol)), rather than if (protocol.equals(“http”)), for example), to avoid NullPointerExceptions in object oriented languages when var is not set.

yoda conditions with java strings can avoid nullpointerexceptions (and you having to check for them):
if (“value”.equals(value)) { … }

Yoda Conditions are quite good to make READABLE code.
You’re rght (blue == sky) is not readable.
But if you think about bigger conditions like

if (TheStuffWhichIsAboveMyHead + TheStuffWHichIsAboveMyHouse + TheStuffWhichIsAboveTheClouds == blue)
(…)

You cannot find out the the constant you’re comparing too in a stressy debug session. A simple rule is: If your IDE cannot display the complete condition when comparing to constants, use a “Yoda condition”.
I’m using Yoda Conditions a lot in bigger code, like
if (false == VariableThatMightBeFalse)
instead of writing
if( !(VariableThatMightBeFalse))

Perl sintax favors Yoda code.

if (evaluation) { do(something) } ;

is valid, but

do something if evaluation;

is valid and shorter, more similar to human speech and yes, you can forget all parentheses.

A wise programming language Perl is.

What about the ‘Diaper construction’: Exception management for catching all exceptions. (see Pokemon Exception Handling).

“To all the people who think Yoda conditions are good: point taken however with experience those errors are easy to spot and even easier to avoid…”

Oh, how naive is he!
On paper good it sounds, yes? But practice is different! Never to mistype “=” for “==”. Always to find in short time from reams of code. Such skill not even a master has!
Not a jedi are you yet.

Another reason why I DO use the yoda notation is that :
CONSTANT.equals(variable)
is less prone to null pointer exception than :
variable.equals(CONSTANT)

I like to have it written in the same way in both cases, and I like the first way when I use .equals().

We use the term “Heisenbug,” too (comment 24)

Jimmy, who just discovered his name is unfortunate

As someone who just spent 2 hrs on tvtropes when I’m supposed to be writing a paper, I second christian’s plea.

I don’t have the time to read all the comments, but the Yoda conditions are actually a good thing.

:-)

PLATYPUS : An application that is a mish-mash of disjointed features. The imagined result of designing an animal by committee: “Let’s add a duck-bill!” “Ooh, and webbed feet.” “I’d like to see something furry”.

This is a great post. I personally hadn’t heard of many of these but found them to be hilarious and definitely reusable. It’s well worth noting that the comment on StackOverflow regarding Yoda Conditions holds very true for many languages. Some programmers use (constant == variable) as it ensures you will receive an error if you forget a = (constant = variable).

A Car,

int x;
public int X { get { return x} set { x = value;} }
// Added by Adam Car
public string sX { get { return “” + X; } set { X = int.Parse(value); } }

Named after the jr dev, who added one of these to every non-string property in the solution.

Useful in java (and c#) for avoiding nullpointerexceptions when using .equals ,
if (constant.equals(variable)) {
… null pointer not possible
}

I spotted another gem in the comments.

“Yoda Programming” — where you never handle exceptions…Because, you know, there is no “try”. – mmyers Mar 16 at 18:13

I offer you “preloopsarian”, a state of programming innocence in which one has discovered assignment and conditions but not iteration.

Love these.

I’m surprised nobody mentioned a pervasively useful “Yoda” in java:

if (“”.equals (stringVar))

This is a lot more concise than:

if ((stringVar != null) && stringVar.equals(“”))

It ‘feels’ just like the other Yoda to me.

Under “Megamoth” I like the “God Object (an object that knows or does too much)” because just today in my open-source artificial intelligence at http://www.scn.org/~mentifex/mindforth.txt I set the AI Mind to activate the concept of “God” when there has been a lack of human user input for a few cycles of thought. The AI does not know anything about God, but the user is invited to start discussing the “God object”.

I’ve never been one to write Yoda Conditions, but I can see how they’d be useful, especially in a language like VB.NET where the equality and assignment operator are exactly the same and the compiler decides which one you meant based on context.

If nobody mentioned it, the yoda condition can be useful in some of the dated programming languages.

“Stringly typed” has got to be my favorite of these. They are very common in programming languages that has no enums (or better yet, variants).

Oh and and by the way before I forget, the yoda conditions can be useful in some programming languages.

I liked the Bugfoot too, although I haven’t really received a lot of those bug reports (yet).

One last thing, did you know that the yoda conditions can be useful sometimes?

Earlize – In the process of bug fixing, leaving changes in the code that did not fix the bug but seemed innocuous. Eventually the project begins to crash as dozens or hundreds of these changes introduce new bugs. Named after a developer who was particularly /good/ at this. “It took 5 or 6 attempts, but I eventually fixed the bug.”

I know a developer who created ‘Comfort UI’ for users – it was an area in a form that did absolutely nothing, but gave the user the impression that they had more power.
For example, in a form to submit a message; the message is unconditionally private, but the user is also given a check box labelled ‘Make this a private message’.

I’m surprised at the number of people that gave the same example to uphold the Yoda bug. There is only 1 example that isn’t bonehead programmer… Java string comparisons (or any good OO language for that matter).

if (SOMECONSTANT.equals(aVariable)) … is the same as

if( aVariable != null && aVariable.equals(SOMECONSTANT))

The first is simpler and you get automatic null checking inside the equals (because any good object should check for null in it’s equals)

Do we have one for blog readers who read the article but not the followup responses to determine whether or not their particular contribution has already been made?

Perhaps “Infinite bloop”.

Re. “unicorny”, we’ve described hardware features like this as “liquid metal”, referring to the Terminator movies.

“They don’t know what they want, so we’ll implement it with sentient liquid metal that can autonomously take the shape of what they say we should have done, after we ship it to them.”

Actually, yoda conditions are just an easy shorthand. Consider (in java:)

if (mystring != null && mystring.equals(“himom!”)) { … }

that’s ugly, and unnecessary, just do:

if (“himom!”.equals(mystring)) { … }

of course, this works best with languages that can compare nullable objects w/ constants, but there, it’s crucial to cleaner code.

x = null;
if (! x.equals(“foo”)) { unreachable(); }
// throws NullPointerException, equals is not a method of null

x = null;
if (! “foo”.equals(x)) { thisWorks(); }

I work with an older gentleman that developed software using early, primitive compilers. One compiler stored constants as variables. For example, the constant 1 was internally stored in a variable with the name “1”. At one point in his code he had the line

if (1 = v)

This caused the constant 1 to globally have the value v. Obviously, this was a nasty bug to find. My old friend loves to tell this story to new developers. Then he goes on and on about how disk drives were the size of washing machines and held only 300 megabytes.

The Hurry Up and Wait Clause.
This is when a project has been brought to team with minimal requirements
and a due date of yesterday. You drop everything you’re doing
to work on it. Spend countless non overtime hours to get it done only to be told that it’s been postponed indefinitely.

Just another benefit to using Yoda conditions in Java and other similar languages:

if(foo.equals(“bar”)) could yield an NPE if foo is null. if(“bar”.equals(foo)) will never crash your program.

Heisenbug:

A bug that occurs differently or not at all in the debugger, but fails in release builds.

In Java, the Yoda condition is useful to avoid NullPointerExceptions.
obj.getValue().equals(“Foo”) can generate an NPE if getValue() returns null.
“Foo”.equals(obj.getValue()) won’t NPE because if getValue() is null, the comparison just comes back as false. Some of the static analyzer tools will tell you to swap your comparison around for this reason.

We’re definitely going to start using Bugfoot at least.

I use the Yoda technique to avoid null pointer:

if (MyConstant.equals(someValueCouldBeNull)) …

Software Escape: Publishing software with known critical and blocking bugs due do an inflexible timeline. Compare to “software release.”

Comments are closed.