a companion discussion area for blog.codinghorror.com

New Programming Jargon


Yoda Conditions are a useful way to force the type of the comparison in dynamic languages, since the left-hand side usually gets to establish the type of the comparison when it could otherwise be ambiguous.

  $num = "5";
  if(5 == $num) { ... }

Even in statically-typed languages, you’ll often have to cast a type, and Yoda Conditions make that more readable than a big Lispy pile of parentheses.

  if(1 == (int)dr["num"]) { ... }   // already has two pair parens
  if(((int)dr["num"]) == 1) { ... } // too many parens

Stateful mental parsing of deeply nested parentheses seems a bigger problem than some Anglocentric difficulty with determining if two things are equal.


@js: I got in big trouble on one project when I “cleaned up” another programmer’s code; mainly, bracket indentation. After much bruhaha, I ended up reverting all of my changes and changed my own style to fit the de facto project usage.


SQL used to actively promote Yoda conditions when you needed to compare a constant with the result of a subquery:

select stuff from foo
where 500 = ( select sum(cost) from bar where id = 1 );

It used to be that you simply couldn’t write the above WHERE expression in non-Yoda form, but things seem to have improved in recent years (e.g., the non-Yoda form now works in both Oracle and PostgreSQL).

Why? Because that’s what the standard said. Orthogonal language design? Who needs that?


Diverge in parallel. A large block of code was copied from one program to another, back in ancient times. Any time a change goes into one, the same change must go into the other, but sometimes the changes are put in different places. Even though the routines do the same thing, and may even have the same lines of code (in a different order), applying patches to both is complicated by the fact that they have diverged in parallel.


don’t touch my favourite Yoda conditions! it creates compiler error when you forget to add double == there.


meta-debugging /me-ta-de-bug-ging/

Verb: The practice of debugging by incessantly asking another programmer how to fix your bug.

Synonyms: stupid officemate - clueless programmer - irritating developer


I love these – thanks to everyone who shared.

FYI, the “duck” is also known as a “hairy arm.” The reference is from commercial art, where the artist purposefully depicts a lovely model with one hairy arm, the goal being to afford his boss a modicum of “added value.”


Pachinko code

Long extraneous code coded with multiple conditional statements that allows control to fall through going in and out of conditions.


@Lu Dicrus
"Dear Diary Version Control" for the practice of using a (D)VCS as your personal save-every-three-minutes notepad.


“Received a Banana”

I was trying to explain to a sales guy that when we asked what to do on failure, we did not mean that we received a “No” from the api, as in he could not sell, where a “Yes” would be success, but that we considered both “Yes” and “No” success, and we considered silence (api down), or “Banana” (unexpected garbage) as failure.

There are four answers to a yes/no question.
Yes, No, Silence, Banana

Thus our it/networking team starting using the phrase “Got a Banana” whenever the incoming response made no sense.


Egyptian code sucks because (a) it doesn’t visually diagram variable scope the way the alternative does, and (b) because when things get hairy, the more complex a block is, the more confused the brackets and the programmer get. There have been many times I’ve fixed a bug just by new-lining Egyption brackets, instantly revealing that the original programmer wasn’t in the part of the loop he thought he was.


Hey #15! Pretty sure this is the most famous I’ll ever be.


This article is a damn plagiarism. Here’s the older source that includes all the “fun stackoverflow jargon” http://www.gamasutra.com/view/feature/6504/a_game_studio_culture_dictionary.php


i like to describe code as brokeass when it is so jacked up you can’t do anything with it …
…and hackasm when you know you hacked something but it felt great pulling off a solution …
…and he verne troyered the code … taking a big-ass class and making it like 3 lines…


@Morphineoverdose, that article was not even remotely similar to this one, with the exception of two terms: Egyptian Brackets and Yoda Conditionals.


I know that Baklava has more layers, but I prefer the term lasagna code because of the obvious relation to spaguetti code.


Clusterfuctoring: when the manager who wrote the original in house application, usually in MS Access, decides to put back the 5000 line MEGAMOTH method you so carefully refactored into nice testable code simply because he can not understand the logic any other way.


Clusterfuctoring: When the manager who wrote the initial in house app, usually in MS Access, decides to put back the 5000 line Megamoth method you so carefully refactored into nice testable code simply because he can not understand the logic any other way.


Have you guys ever experienced the “Déjà bug”. That bug, that it’s definitely new but you think you have already fixed in the past?


Great article! We use a fun term that I could not even find at the Jargon File. There it goes: What do you call a bug that appears, even though you remember to have solved before (often several times)?

A déjà bug.