Sunday, November 27, 2011

What programming terms have you coined that have taken off in your own circles (i.e. have heard others repeat it)? It might be within your own team, workplace or garnered greater popularity on the Internet.

Refer to the Wikipedia entry on Indent style for further reading, including 1TBS (The One True Brace Style), Allman style (also known as ANSI style) and Whitesmiths style.

Different kinds of bug reports

Smug Report - a bug 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. by [aaronaught]

Drug Report - a 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 to have had one too many. by [aaronaught]

Shrug Report - a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work." by [aaronaught]

Fermat's Last Post - a post to a bug tracker/email list/forum in which the author claims to have found a simple fix or workaround for a bug, but never says what it is and never shows up again to explain it (even after others have been puzzling over the bug for years). by [alan moore]Floater - the case in a bug tracking system where a bug report remains "floating" at the top of the queue, but never gets assigned to a developer, maybe because there is a workaround in place.

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.

A play on the term Refactoring which was popularized by Martin Fowler in his book of the same name.

Stringly Typed

An implementation that needlessly relies on strings when programmer and refactor friendly options are available. For example, method parameters that take strings when other more appropriate types should be used. Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.

A play on the term Strongly Typed, code which restricts the mixing of different or incompatible data types, allowing errors be picked up at compile time.

Different kinds of bugs

Heisenbug - a bug that disappears or alters its characteristics when an attempt is made to study it. by [jacob]

Higgs-Bugson - a hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don't really know if it's there, and if it is there what is causing it. To find these you will need to invest in a Large Hadron debugger. by [runrunraygun]

Schrödinbug - refers to a function/feature that appears to fluctuate between buggy and correct (like Schrödinger's cat, fluctuating between alive and dead), until somebody looks at the source code (opens the box), at which point it becomes permanently bugged. by [aaronaught]

Loch Ness Monster Bug - a bug which cannot be reproduced or has only been sighted by one person. by [russau](Also, Bugfoot is a great alternative).

UFO bug - a bug presented by customers, who, even when they're shown that it doesn't exist, will repeatedly report it again and again, believing it is real. by [Tuqui]

Mandelbug - a bug whose causes are so complex that its behavior appears chaotic or even non-deterministic. Named after fractal innovator Benoît Mandelbrot. by [coehlo]

Brown-paper-bag bug - a bug in a public software release that is so embarrassing that the author notionally wears a brown paper bag over his head for a while. by[ESR via Jargon File]

Sorcerer's apprentice modebug - a bug in a protocol where, under some circumstances, the receipt of a message causes multiple messages to be sent, each of which, when received, triggers the same bug. by[ESR via Jargon File]

Mad girlfriend bug - a bug whose immediate effect remains hidden - the app outwardly seems to function normally and tells you that everything is fine. by [jeduan-cornejo]
Excalibur bug - when all of the developers within a company have tried to fix a particular bug but none are worthy have succeeded, so far.
Load-bearing printfbug - when a line of debug output is required for the code to work - the code does not function if you remove it. by [Ken]

Doctype Decoration

When web designers add a doctype declaration but don't bother to write valid markup.
by [zurahn]

New software features

A Unicorny - A feature that's so early in the planning stages that it might as well be imaginary.

A Barack Obama - A feature we'd really like to add to a project but will probably never get approval for.
by [jordan]

Different types of Code

Spaghetti Code - Code that's got one too many GOTOs, exceptions, threads, or other "unstructured" branching constructs. Program flow tends to look like a bowl of spaghetti - twisted and tangled.

Spaghetti with Meatballs Code - An attempt at object-oriented code, but where the end result still remains dependent on some messy procedural (spaghetti) code.

Baklava Code - Code with too many layers. Also known as Lasagne Code. by [john-d-cook]

Ravioli Code - Object-oriented code consisting of a number of small and loosely-coupled software components.

Sausage Code - Once you've examined the code in detail ("how it's made") you'll never want to use it again.

Jenga Code - The whole thing collapses when you alter a block of code. Also known as Crispy Noodle Code.

Hydra Code - Code that cannot be fixed. One fix causes two new bugs. It should be rewritten. by [nick-dandoulakis]

Scar Tissue Code - Any code that is commented out but still included in the current and/or checked-in version. by [kelly-french]

Pig's Lipstick Code - Code which has large amount of legacy and/or spaghetti code hidden via wrapper objects, so while it appears to new developers to be well designed, elegant, object-oriented code, when they start working on it in depth they realize just how ugly it really is.

Cut-and-waste Code - When someone cut and pasted code they found online (usually from a blog) into a production product; the result is usually a lot of wasted time trying to track down an obscure bug from code that undoubtedly made sense in the original context but not in our app. Also known as BDD - Blog Driven Development.

Neighborhood Bike Code - A module or a piece of code that every programmer at the company has touched.

Eraser Stains Code - Code that has been written, then re-factored multiple times leaving swaths of legacy code and design. Like erasing a sheet of paper so many times, the pencil marks are no longer the problem - the large greasy stain is.

Objectfuscated Code - Object-oriented code which has been abstracted to so many levels that no-one can understand it anymore.

Barnacle Code - Any piece of code (usually a static method) which has been appended to a class where it doesn't really belong, due to a lack of anywhere else to logically put it.

Autopilot Code - Code that was written by a programmer who was on 'auto-pilot' or wasn't really thinking about what they were doing.

Fear Driven Development

When project management adds more pressure (fires someone or something).

Yoda conditions do have good uses though; for instance they protect you from accidentally doing a = 5 (since you cannot do 5 = a) and they protect you from null-pointer dereferences in Java/C# (5.equals(a) cannot throw whereas a.equals(5) will if a is null).

if null is a possible value i'd rather check that too than silently ignore it with a yoda condition. in .net it would e.g. be string.IsNullOrEmpty(string). if i don't expect a null value i'd like an exception!

@id: 5.equals(a) isn't valid in Java. Anyway, in Java, if (a = 5) will not compile at all. The only syntactically valid form is if (b = true). That's why I often advise to use just if (b) (with a good boolean name to make this reading like English, like if (isValid)) as it is both non-redundant and less prone to typos.

This actually may be the only valid reason to use yoda conditions. However, if you're going to have to be jumping through hurdles to avoid the overloaded operator, you should probably weigh the pros and cons about overloading ==.

I've referred to "Anecdotal bugs" for years: those are real bugs that cannot be reproduced at will and do not have any data available for debugging, but which are worth reporting *and closing as unfixed*. That way if multiple customers report it, eventually (hopefully) enough details are collected that it can be fixed, and you can tell all the reporting customers, making them happy (well, happier).

Another possible interpretation of the Stockholm Bug is something I see occasionally, where a bug is actually treated as a feature by a customer and integrated into their process (the customer is the hostage in this scenario). Inevitably another customer raises it as a bug and there's a bun fight over whether it gets fixed.

The Stockholm Bug comes up often if the bug occurs under exraordinary condidions - and as such is experienced rarely by users - but has hilarious consequences.

I worked on a CRM, where if the 'Country'-field was changed from the default value while creating a new customer into the system, the CRM would repopulate all the other field with values from random customers already in the database. Everyone felt a little down for a while after the bug finally got squashed, just because it was like a messed up version of mad libs debugging the thing.

I once came up with "Fermat's last post", which is a post to a bug tracker/email list/forum in which the author claims to have found a simple fix or workaround for a bug, but never says what it is and never shows up again to explain it (even after others have been puzzling over the bug for years).

Our database application is Hydra Code (I LIKE that term!) with about 20 years of development invested, going back to the early days of DOS programming. One of its lovely features is that certain record sets must follow the Highlander Rule: there can only be one.

"murphy-code": incorrectable code; code that keeps filling up with errors (similar to Murphy's law that what can go wrong, will go wrong)

"death clock script": a line or lines of code that alter the physical system in order to effect a change for the program. An example would be a game that forces 256-bit color to run.

"Minesweeper development": For every error you fix, a bunch more develop until eventually the whole thing just blows up.

"The U-Boat": a phenomenon that occurs when two or more people are editing the same document at the same time, where each person's changes cause the other people to completely lose track of where they were and what they were doing. Also called "The Phantom Menace" or "Phantom Coding"

I once was working on some legacy code in a telephone switching system and saw code labeled with "PFM" in several different (and critical) places. I asked one of the senior engineers about it and was told it stood for Pure 'Freaking' Magic. Needless to say, I have perpetuated this moniker!

@Ken (Load bearing printf) that's awesome and has happened to me once before... the debug statement remained in production software without the customer ever knowing about it. I've added it to the list of bug types.

@AlbertOne (The Wormhole bug) awesome and totally possible. A little bit similar to the load-bearing printf. As a matter of fact, developments in Quantum Entanglement could some day bring about a whole new class of these types of bugs... ;-)

@Dodgy_Coder the load-bearing printf is a line that you don't know why it causes the code to work (and on the other hand why the code doesn't work without). The Wormhole bug is effectively a bug, but the consequences appear in a very distant part of the code where you don't expect it.

A Quantum Entanglement bug could be a bug that causes a malfunctioning in another program or distant PC! ;-)

The Möbius Conditional: when coding does not take into account that a circumstance may meet more than 1 condition; typically occurs when changing over from multiple IF... THEN statements to a SELECT/CASE statement as would be used in a FizzBang solution.

As for the Yoda Conditional, I have not used it before; but, I was inspired by it and tried it within a Sql statement...

@Unknown (Test Constrained Architecture) nice ... that sort of constraint might be eliminated by the replacement of your existing test code with 'Ninja Tests' - as with Ninja Comments, Ninja Tests are so small and awesome that they cannot be seen - in fact there is none there at all. ;-)

'69 Code'- where two separate modules have references of each other and call each other's functions or set flags. After few days none of the programmers knows what is happening in either of the modules and who is doing it.

"Pasta code": code that is a mix between spaghetti code and lasagna code, layers of spaghetti code, for when a library or class made out mostly of spaghetti code is used in other spaghetti that builds a framework around (saw that one a lot at my former employer).

In the Foswiki project, the term "pre-deoptimization" is used to describe either features or code that are arbitrarily crippled or overly convoluted in the name of performance, but actually create new bottlenecks and slowness.

@hogbag ... thanks, 'Cruft' is a great term that I'd heard used around the place. I am amazed at the origins of this word ... apparently there was a place at Harvard called 'Harvard University Cruft Laboratory', which was the Harvard Physics Department's radar lab during World War II. As unused technical equipment piled up in the building in the decades after the war, the piles of gear became known as 'Cruft'. From there, the idea of "discarded technical clutter" migrated from hardware to software. [Refer to the wikipedia entry here for details.

A-Bug (Apocalypse Bug or Atomic-Bug) - A bug that crashes the OS and eliminates any form of crash data, effectively putting you at square one and usually forcing you to step through every line of code.

Maintaining windows driver code with no relevant BugCheck information, which happens to be a driver that affects the system's ability to write the mini-dump data, is a rather annoying, dangerous, and pain-inducing bug.

Host A is replying to Host B after a task is finished in some specified time, however, Host B was waiting for the reply during the same specified time and resulted failure. Simultaneously, Host B receives the reply, but Host B already decided it has been failed. I call this 'Romeo and Juliet Bug.'

At my company we've been using "Bimboware - an application that looks good on the outside, but is quite shallow on the inside". Might be the product of a protoduction app or some form of RAD method. Performs well on your three-record dev database, but halts on your real life production system.

Then there is the Wiederganger Bug, that returns from the grave in every release until the feature is dropped.

I have another reason for yoda conditions: often people hide the actual comparison after a long line of accessor methods, when the condition starts with the comparison, I can usually grasp the intent of that condition much quicker.

I love these! Having been a programmer since '84, I've seen almost all of these.

FWIW, load bearing printf bugs usually mean that you've got an argument mismatch in a function call. Move the printf around until you find the spot where it stops/starts helping and check the argument type/size/counts on the functions near that spot.

Choose Your Own Adventure Code - Code that eventually ends up crashing in many different ways and only has one happy path.

Cargo Cult Code (Stone Radios) Anti Pattern - Code that resembles a recommended consistent pattern, but misses the point and therefore never works because of terrible implementation.

Life Support Anti-Pattern - Making small imperceptible changes like guard clauses and exception swallowing - doesn't do any good, but may inadvertently result in placebo-like relocations of the issue to another piece of code.

@Smakkie: Recently (like the new Android (and thus Java) compiler) would warn/advise about set but unused variables. I think many compilers are starting to go that direction. Nevermind that one (or several) variable(s) are going to use very little memory space... unless they're huge array(s) full of useless crap that then still doesn't get used.

I like the term "Search and Destroy" coding. Similar to Cut n Waste, they search the Internet, find some code they don't really understand, then Paste & Pray.Often there is a whole lot of other artifacts, exceptions & caveats that go with that set of classes. And now your production code doesn't consider any of them. ;-)

Something I recently Ran into : WTH Programming: Where a programmer is forced to use a different language than what they normally use and the syntax (that would be simple to some one who programs in the Language) turns into 14K worth of lines of Code.

Periodic bug. Often mistaken for a Deja Vu bug. A bug that seems to reoccur at regular predictable intervals. Perhaps because of hardcoded solutions to daylight savings issues. One periodic bug I experienced was reported by two different people at opposite ends of the business cycle. Both were using the same tool, but complained a boolean value was getting set wrong. Of course, one of them wanted it to always be true and the other false. After a couple of years I noticed what was happening and added a checkbox to the form, and made the system remember whether it was last checked or unchecked for each user...