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
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
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
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
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
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
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
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
The act of using
if (constant == variable)
instead of
if (variable == constant)
It’s like saying “If blue is the sky”.
367 replies on “New Programming Jargon”
The last one, Yoda Conditions, I see all the time. Never made sense to me, but now I know what to call them. :D
yoda conditions are preferable in legacy code in certain statically typed languages
The Yoda Conditions are useful to avoid if (variable = constant) errors.
Yoda conditions are actually a good way to remove visual ambiguity between affectation and equality operators. x = 5 is an affectation whereas 5 == x can only be a comparison.
Enbug – the process of creating bugs (that need to later be debugged)
Alternate definition for ‘Refuctoring’: When the refactoring helper tool completely destroys your code.
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…
We had a ticket resolution status in our tracking system called WAD, short for Works As Designed. We on the test team coined the term WADDLES: Works As Designed – Designed Like S**t to describe poorly implemented features.
An Imperial Feature
A feature that is unilaterally added to a release (usually by the CEO and usually late in the cycle) without any requirements or justification other than the CEO wants it. An Imperial Feature trumps all other features and thus gets whatever resources it needs to make the release.
Also known as “a Piccard” as in “Time Travel, make it so.”
The Yoda condition actually makes sense in some situations to protect against using the assignment (=) operator instead of the comparison (==) operator in your conditional statement. Protects the value in the variable from getting stomped on in the comparison.
if (5 = count) {
// tries assignment, fails, leaves value in count alone
…
}
vs.
if (count = 5) {
// reassigns count to the value 5, returns true, process following code, value in count lost
…
}
Granted the code above is wrong in both cases (assignment rather than comparison) but I find the first easier to debug as the count variable hasn’t been compromised.
> It’s like saying “If blue is the sky”.
You mean, it’s like saying “If blue the sky is”
I always thought yoda always uses ‘is’ at the end of a sentence. :)
[…] New Programming Jargon — Global Nerdy (tags: development programming) […]
Yoda condition probably mean someone worked on a compiler that would silently accept if (variable = constant), when you meant ==. Putting the constant first made typos into a compiler detected error, instead of a run time bug.
Fiddling and Twiddling
The process of fiddling with code (for example by unwinding a bug back to the first line of main() and learning that it happens in a constructor) whereby at the end of the day you have not accomplished the critical one thing the leads to progress over time. In other words, perhaps you would have been better off twiddling your thumbs instead.
Around our office the term “Hurked” has come to mean any generic failure for an unapparent reason.
no clue if it’s just us.
ie;
“Whats up?”
“My code is hurking all over the place”
don’t forget the dreaded whack-a-mole bug, a byproduct of the flying spagetti monster application structure.
Siegfried Clarke: The term “hurked” reminds me of the Hungarian “Hurka” commercial:
There actually is a good reason for Yoda Conditions…
Yoda Conditions are a common way of avoid the occasional
if(count = 5) issue.
It’s been almost two decades since I was a programmer, but I understand most of these. Except the “Yoda condition”. It looks wrong, but does it do the wrong thing?
[…] full post on Hacker News If you enjoyed this article, please consider sharing it! Tagged with: Jargon • […]
The yoda condition can actually be a good thing sometimes. It can catch bugs in which someone meant to do a comparative test but does an assignment instead. E.g
if(a = constant) is correct but you may have meant
if(a == constant)
a compiler will not usually (without proper warning options flag the first item but it will cact
if(constant = a) and raise an error.
I laugh a lot with much of the new jargon, but the last one, the “Yoda condition” is well described, but it is presented like a bad thing, but it actually it could be a GOOD thing, in C/C++ language.
What is the difference between this two lines of code?
if (my_val == 314)
if (my_val = 314)
First one is comparing my_val against 314, and it is true ONLY when my_val value is 314.
Second one is ASSIGNING 314 to my_val, and as it is different from 0, it is ALWAYS TRUE.
As the second line is always TRUE, it has no sense to have it inside a if statement, and it is very probably a typo where the programmer missed to add the second ‘=’ to the code.
What is worst, the compiler probably WILL NOT complain in any of both cases, masking that error unless it really produces an explicit bad behavior.
I have done that mistake a couple of times, and it is embarrassing. How to prevent it? guess what, the Yoda trick helps here:
if (314 == my_val) /* The comparison is valid */
if (314 = my_val) /* The LHS is a constant and cannot receive an assignment => compile time error! */
Therefore, the Yoda conditions are actually useful for writing health code.
I work in a storage company, where “Filers” is associated with female crowd and “Servers” with male crowd. :D
Hi,
Superb post. :)
Our term is: Biscuit Loop
The biscuit loop is a dumb but sneaky trick to show that the software is doing something heavy while all we are doing is running empty loops. The purpose of Biscuit loop was to fool undergrad supervisors in VTU to show that we actually worked seriously on our projects.
Heisenbug – a bug whose behavior changes, or even vanishes, when you attempt to debug it or observe it in process.
The last one is actually useful in C/C++ where accidental assignment is used in conditionals
if (constant = variable)
is a compile error, and
if (variable = constant)
is a warning or less
some of those are really amazing….great…
I feel the .net sandwich should also be called the KFC double down.
if (5==count) makes sense because this will cause an error in some languages: if (5 = count)
but this will not: if (count = 5)
yoda condition, wisefull is….
Just as a side note: Please refrain from linking to TVTropes. It’s not nice and has just last year wasted so much productivity, one could run a middlesized country on it.
“Prestige Worldwide” (from the movie step brothers). The act of over hyping & over promising features and revisions that realistically will never happen or see completion. Usually presented by immature associates with a marketing/SEO background that endeavor to impress upper management only to be fired months later once funding runs out.
Regarding Yoda conditions:
In Java, it is preferred to write conditions that way, mostly because .equals is often used instead of == and .equals can have null pointers:
final static String myConstant = “Something”;
String myVar = null;
if (myConstant.equals(myVar)) //fine
if (myVar.equals(myConstant)) //NPE
Nice post. My personal favourites are “Pokemon Exception Handling” and “DOCTYPE Decoration”.
PS I think that someone needs to point out that Yoda conditions can be useful, no one seems to have mentioned it yet ;)
I have a couple.
Donut:
Your base, base, base markup/css/js. It’s a bunch of layout and functionality with a hole in the middle where content, sub templates and innerHTML goes.
Interactive Learning Tool:
A blunt object like a baseball bat or 2×4 with “interactive learning tool” written on it. Kept somewhere close by and reflected upon when whomever asked for the piece of technology you’re working on needs to be educated about how the web works or what a server is. It’s more of a mascot than anything else.
Oh come on people, the Yoda condition is NOT a good thing, because you are optimizing for code writing, when code is read (and maintained) a lot more than it it written.
Also some (dynamic?) languages, like PHP and JavaScript, support a === operator, which is much more preferable to the == operator and you’re less likely to make a typo (I certainly never have…).
Hey guys I didn’t read the last 13 posts claiming that yoda conditions are actually good so I’m just posting to say, hey guys yoda conditions are actually good because it stops you from assigning constants to variables.
You are missing the famous “Black Triangle” http://rampantgames.com/blog/2004/10/black-triangle.html
If you can’t grasp the meaning and difference between assignment and comparison operators and have to rely on using Yoda conditions to avoid it, perhaps you shouldn’t be programming.
I always liked the term Heisenbug. As you might guess, it describes a bug that is nearly impossible to reproduce. The bug reports never have repro steps and often contain hearsay.
Yoda conditions are alo useful in Java where you don’t know if a String object is null or not (and don’t want to test it first, for whatever reason.)
if (“my constant string”.equals(someString))
will never throw a NullPointerException.
My colleague had a good one to describe a particularly bad idea I had wherein two discrete systems would maintain their own records of the same data:
Freedom of Information Act Pattern
‘Yoda condition’ is hilarious. I don’t use those myself, though I’ve been caught by that style of bug a couple of times. It’s easier to fix those than to get used to that odd style.
Both PHP and JavaScript allow assignment in a condition. Python gives a syntax error, and Ruby gives a warning.
We use the term fell over extensively in our offices when something just stops working completely.
We also have a reason. At one time our entire operations ‘fell over’ and no-one could figure out why. Turns out one of the cleaning ladies had cleaned the server room and our dev server was lying on it’s side in pieces. She just said “It fell over!?”
Can somebody please explain why the Yoda conditions are useful? I must have missed it.
I like Yoda; in:
if(5 == my_long_special_variable_name)
I instantly see the value “5” (which I’m generally more interested in), where here:
if(my_long_special_variable_name == 5)
I have to search it…
So, my reason to do so is simply readability.
you don’t need yodas in C++:
if( const_cast(count) == 5)
if( const_cast\(count) == 5)