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.
Reposting some of the best ones below ...
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo).
Because it's like saying "if blue is the sky" or "if tall is the man".
by [zneak]
Originally, yoda conditions might have been introduced to reduce the potential of coding errors in the form if (5 = count) which would be picked up at compile time.
For when you just Gotta Catch 'Em All.
try
{
// do something
}
catch
{
// catch em all
}
by [woot4moo]
The style of brackets where the opening brace goes on the end of the current line ...
if (a == b) {
printf("hello");
}
This style of brackets is used in Kernighan and Ritchie's book The C Programming Language, so it's known by many as K&R style.
by [computronium]
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.
by [dan-vinton]
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.
by [mark-simpson]
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]
Hindenbug - a catastrophic data destroying bug - "Oh the humanity!". by [mike-robinson]
Counterbug - a bug you present when presented with a bug caused by the person presenting the bug. by [mike-robinson]
Bloombug - a bug that accidentally generates money. by [mike-robinson]
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 mode bug - 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
Load-bearing printf bug - 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]
Hooker Code - Code that is problematic and causes application instability (i.e. the application "goes down" often).
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.
Mortgage Code - Code purposely so terrible and complicated that only you can maintain it, forcing your employer to keep you, thus providing job security (so you can pay your mortgage).
Ghetto Code - A particularly inelegant and obviously suboptimal section of code that still meets the original requirements.
Swiss Army Code - Application code that is suffering from feature creep - it does a lot of things, but it does nothing well.
NP Tricky Code - An algorithm whose complexity is too hard for a mere mortal to figure out.
NP Hilarious Code - An algorithm whose complexity is "a joke", literally (as in BogoSort) or metaphorically.
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.
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).
by [arnis-l]
Protoduction
A prototype that ends up in production.
by [chris-pebble]
Ninja Comments
Also known as invisible comments, secret comments, or no comments.
by [schar]
Smurf Naming Convention
When almost every class has the same prefix.
by [sal]
Veedubbing
To alter the algorithm of a software system for given known test inputs, or test conditions, to make the software appear to perform better than it really is.
[source][example]
Thanks again to the above answerers from the original StackOverflow question:
[zneak][woot4moo][computronium][aaronaught][dan-vinton][mark-simpson][jacob][runrunraygun][mike-robinson][russau][zurahn][jordan][john-d-cook][arnis-l] [nick-dandoulakis][chris-pebble][schar][sal][kelly-french][jeduan-cornejo]
And to the original poster of the question: John K
If you have any good suggestions, please add some comments below and I'll update the post.
Follow @dodgy_coder on Twitter
Heh, nice.
ReplyDeleteYou are missing "Hate Driven Development" for when the code you just saw is SO horrible and stupid that you JUST. MUST. REWRITE IT.
It happens.
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).
ReplyDeleteYeah nice idea, but in Java you can't call equals() on a primitive ;)
DeleteYou could do that in Ruby though...
Except that you can since, like, JDK 1.5. It's called autoboxing.
DeleteSuper useful for strings as well:
Deleteif("".equals(possiblyEmptyString)) {
// no need for null check
}
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!
DeleteAbsolutely hilarious article, thanks for brightening up my day. ;D
ReplyDeleteyou missed: Crispy Noodle Code - like spaghetti code but when you touch it it breaks.
ReplyDeleteIt's there under the name Jenga code
DeleteI new the Higgs-Bugson as Bohr Bug because of the quantic physics nature of it and I had two more on my list
ReplyDeleteMendelbug : Chaotic bug caused by a huge number of factor.
Schrödinbug : Crash provoked by an external action, not code related crash. (resource substraction)
I always wondered about Yoda Conditions. The idea is good, but practically, I find it non-usefull because you cannot compare non-const variables. And I bet you have a few of those. Example:
ReplyDeleteint foo = f();
int bar = g();
int baz = h();
if( foo == bar )
{
bar += baz;
}
Nice one. I'd add the "Sausage code", the one that, once you know how it's done you won't ever use it again.
ReplyDeleteDon't forget the UFO bug, a bug presented by the customers and even when it's show that it doesn't exist/it's not there, they will report it again and again believing it is real.
ReplyDelete@Tuqui (UFO bug) nice, thanks - I'll add that to the list.
ReplyDelete@Galvão (Sausage code) - been there before! similar to "black box code" I suppose, when you don't know or care about what's happening inside of it.
@coehlo, thanks, I've added Mendelbug to the list.
ReplyDeleteThese days, your compiler will prevent you from writing if (x = 5) via a warning.
ReplyDeleteSome compilers, in some languages, but not the one you are using today.
Deletecsc (c# compiler) won't compile at all this:
ReplyDeleteif(x = 5) {}
as an assignment is neither true or false.
I use Yoda conditions in JS.
You could however mistake a boolean assignment for a comparison in both C# and Java
Delete@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.
ReplyDeleteI use the term "anti-bug" to mean incorrect code that nevertheless seems to work correctly.
ReplyDelete"Quantum Debugging" When someone stands over your shoulder to see an error occur, the error no longer occurs.
ReplyDeleteI call that one a Proximity Bug.
DeleteI call that one a Mechanic Bug or Programming by Fear Fix.
DeleteThis comment has been removed by the author.
Deleteyou can have a "quantum memory leek" however, a memory leek which disappears when an attempt is made to investigate it with a profiler.
DeleteDon't forget
ReplyDeleteSPEC BUG.
A specification that if followed will make a bug.
If you code in a language where constants does not have methods, Yoda conditions makes sure that you don't unintentionally use an overloaded "==" method.
ReplyDeleteThis 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 ==.
DeleteI'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).
ReplyDeleteStockholm bug - Having a bug so long that eventually you express empathy and have positive feelings towards it.
ReplyDeleteAfter fixed you'll usually hear "Aww i liked that bug!".
@Jerry LaGrou (Spec bug) nice, could also be called a "bug by design".
ReplyDelete@JFarrand (Stockholm bug) now that is the product of a sick mind. I like it. ;-)
@phsiii (Anecdotal bug) nice - sounds a bit like a Loch Ness Monster bug.
This was an awesome read, thank you! :-)
ReplyDeleteMany of these have the hallmark of good humour: I kept finding myself saying "That always happens to me! / I do that!"
+1 for the Stockholm Bug. I've seen it happen. It's mad, but it's true. :)
ReplyDeleteAnother 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.
ReplyDeleteI could definitely see this happening.
DeleteThe Stockholm Bug comes up often if the bug occurs under exraordinary condidions - and as such is experienced rarely by users - but has hilarious consequences.
ReplyDeleteI 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.
And don't forget the Sherlock comment:
ReplyDelete//Set a equal to b.
a=b;
(No shit, Sherlock!)
Lots of talk about "bugs". A manager I reported to back in the 90s once told me, "There are no bugs, only undocumented features."
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteVery nice...^_^
ReplyDeleteTHank yu...
Yoda conditions do work with select case / switch too:
ReplyDeleteSelect Case True
Case opt1.checked
'do something
Case opt2.checked
'do something else
Case opt3.checked
'fuck everything
End Select
I've taken to using "objectfuscate" when I see someone taking the concept of abstraction far too far.
ReplyDeleteYou should add what I call the "Load-bearing printf", which is a line of debug output that should not be necessary for the code to work, but nonetheless, the code does not function if you remove it.
ReplyDeleteI 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).
ReplyDeleteDebris Code
ReplyDeleteNon-functional code left over from previous versions. Code someone was too lazy to delete or too afraid it did something somewhere else in the code.
As a man of faith, I am often reminded of my need for "Prayer Programming", which is tightly coupled with "Trust Driven Development" (TDD)
ReplyDelete@Alan Moore. +1 on Fermat's last post
ReplyDeleteI like the "load-bearing printf" quite a bit.
ReplyDeleteOne of my personal favorites is the "OB one" (pronounced Obi-Wan), which of course means a loop that doesn't work correctly because your logic is "off by one".
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.
ReplyDeleteThe Palestinian-Israeli BUG : when there is a bug involving two software from two company and they both say "it's their fault they have to fix it"
ReplyDelete"murphy-code": incorrectable code; code that keeps filling up with errors (similar to Murphy's law that what can go wrong, will go wrong)
ReplyDelete"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"
The Henny Youngman Bug:
ReplyDeleteCustomer: "Developer, it crashes when I do this"
Developer: "Then don't do that"
Often a sign of extreme creativity on the part of the customer. ("Wait: Step three is 'unplug your network connection?'")
Error 415 - The error is between the Chair and the Keyboard
ReplyDeleteI 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!
ReplyDelete@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.
ReplyDelete@Alan Moore (Fermat's last post) that's pure gold ... I've added it above.
Good article.
ReplyDeleteThe Wormhole Bug
ReplyDeleteA bug in a part of code that causes malfunctioning in another distant and supposedly separated part of code.
If ever there was a good read, followed by just as well written(thought out) comments this is it. Esp. from a Computer Science student point of view
ReplyDelete@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... ;-)
ReplyDelete@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.
ReplyDeleteA Quantum Entanglement bug could be a bug that causes a malfunctioning in another program or distant PC! ;-)
an other term for "hydra code" is "jenga code": you touch it at one place and falls apart everywhere else.
ReplyDeleteI think it could be named also "domino code" :)
DeleteThe 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.
ReplyDeleteAs for the Yoda Conditional, I have not used it before; but, I was inspired by it and tried it within a Sql statement...
Original: Select * From [table] Where (This = 1) Or (That = 1)
Yodafied: Select * From [table] Where (1 IN (This,That))
@Mad Myche - I like your Yoda conditional in Sequel (also known as "Yoda in The Empire Strikes Back") groan ;-)
ReplyDelete@Bence Erős (Jenga code) nice - or could it be that if you remove one line, the whole thing falls apart ;-)
ReplyDeleteOoops I wish I had known the Yoda condition, it would spare me so many ackward UFO bugs...
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteTest Constrained Architecture:
ReplyDeleteWhen your code could be greatly simplified by a certain refactoring, but you'd need to redesign tests in order to change it so you don't bother.
@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. ;-)
ReplyDelete'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.
ReplyDelete"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).
ReplyDelete"alien code": code that makes ANY static analyzer crash
As an amplification to "69 code", I propose "Orgy code", the same, but with several intertwined modules.
ReplyDelete@3dPrasad (69 Code) ... classic, sounds very much like some legacy FORTRAN code I worked on where functions modified global flags instead of passing parameters around.
ReplyDelete@Kurisu (Pasta code) ... that sounds very much like Object Oriented Programming's arch nemesis - Object Oriented Pasta.
ReplyDeleteIn 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.
ReplyDeleteThere's a great explanation here of why yoda conditions are so hard to read, and seem unnatural ... Extract from 'The Art of Readable Code'
ReplyDeleteIndustry standard word 'Cruft' should cover these two; 'Scar Tissue Code' - and 'Debris Code', and has the advantage of being a made up word that also somehow sounds like it's meaning.
ReplyDelete@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.
ReplyDeletehahah hilarious. This made my day :D
ReplyDeleteGreat great great article. Thank you!
ReplyDelete"... Allman style (also known as ANSI style) ..."
ReplyDeleteAllman style is referred to as "ANSI style" in the astyle documententation, but that's incorrect; all versions of the ANSI and ISO C standard use K&R / 1TBS.
See the updated Wikipedia article.
Hi Keith, thanks & sorry for the late reply - I will update this. I was also under the impression that Allman == ANSI style ever since I started programming.
DeleteGreat list yet, Smurf Naming Convention: When almost every class has the same SUFFIX
ReplyDeletePapa Smurf, Brainy Smurf, etc.
Chtulu code, a code back from the old age and so horrible that you can't even try to read it without a great chance to loose your sanity.
ReplyDeleteLOL, really loved that one! xD
DeleteSloppy Paste - When a piece or fragment of code is copied and not adapted completely to match its new context.
ReplyDelete"Pig's Lipstick" is known as "covering shit with whipped cream" where I work. ;)
ReplyDelete+1 for the Stockholm bug :D
ReplyDeletehttp://www.reddit.com/r/gaming/comments/uodjr/im_a_guild_wars_2_developer_ama_about_the_next/c4x4oac
Grat article, thanks!
Matrix bug: An impossible bug that the only explanation for it happening is that you are living in Matrix and it failed.
ReplyDelete(The bug I am having now btw)
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.
ReplyDeleteMaintaining 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.
great list!
ReplyDeleteThis comment has been removed by the author.
ReplyDelete(original text) https://twitter.com/imays/status/236734302409351168
ReplyDeleteHost 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.'
Magic Spell Code:
ReplyDeleteif (that.get_part().accessToSubpart().transmogrify_it().isWhatever()==6) ...
Has lots of steps and some magic contents. Not even Yoda can shed some light on it
"Baklava Code - Code with too many layers. Also known as Lasagne Code. by [john-d-cook]"
ReplyDelete- what I like to refer to as "Inception Code"
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.
ReplyDeleteThen there is the Wiederganger Bug, that returns from the grave in every release until the feature is dropped.
ReplyDeleteI 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.
The "Disclaimer Bug". this is a bug reported by the customer that is actually a new requirement but the customer does not want to pay.
ReplyDeleteI love these! Having been a programmer since '84, I've seen almost all of these.
ReplyDeleteFWIW, 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.
I have the following additions (Mostly due to out-sourcing):
ReplyDeleteChoose 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.
Homoeopathic Anti-Pattern - Creating interfaces that promise incredible underlying implementations, but never actually provide the claimed behavior. Ex: ITransactionalAndRecoverableBatchProcess.java - implementation is neither Transactional or Recoverable.
Hi Lex, thanks for these comments, they sound like really inventive ways to kill off a codebase ...! ;-)
DeleteWe have The Compatibility Bluff: saying the product is compatible with legacy software when it hasn't been tested or the tests had horrific results. Like: should work on Win98.
ReplyDeleteThe bluff is generally low risk as the small percentile of clients using these dinosaur systems don't update our software either and our bosses have no clue on how to check legacy compatibility.
Oh, and Variable Amnesia. It's a condition where one defines a variable but never uses it.
DeleteSome more jargons we use are, Chaos methodology, and PDD (Panic Driven Development)
ReplyDelete@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.
ReplyDeleteI 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.
ReplyDeleteOften 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. ;-)
nike software development - just do it
ReplyDeleteWack-a-mole bug. A bug that when fixed results in one or more new bugs ad infinitum. The type of bug produced by Hydra Code.
ReplyDeleteSomething 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.
ReplyDeleteI'd add "quantum memory leek": a memory leek which disappears when an attempt is made to investigate it with a profiler.
ReplyDeleteas a case of the Heisenbug
"Excalibur bug"? "Excalibug" sounds better to me :)
ReplyDelete+1 to Excalibug.
ReplyDeleteAlso rename Veedubbing to Volksbuggen, given the recent events with the car brand.
Rename (or alias) Pokemon Exception to a better used name I learned today: Diaper Pattern
ReplyDeleteDeja Vu Bug. A bug that you can swear you fixed before.
ReplyDeletePeriodic 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...
Untesting: when unit test failures are dealt with by being hurriedly re-written so that they pass, without checking whether the change breaks anything.
ReplyDelete"Excalibur bug"? Missed opportunity, there.
ReplyDeletethis made my day, and possibly my week. Thanks for posting!
ReplyDeleteOriginally, yoda conditions might have been introduced to reduce the potential of coding errors
ReplyDelete