Sunday, November 27, 2011

"Yoda Conditions", "Pokémon Exception Handling" and other programming classics

Just reading through some of the excellent answers to this question posed on StackOverflow.com by John K

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 ...


Yoda Conditions


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.

Pokémon Exception Handling

For when you just Gotta Catch 'Em All.

try
{
    // do something
}
catch
{
    // catch em all
}

by [woot4moo]


Egyptian brackets

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 are worthy have succeeded, so far.

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 Codeby [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.





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]










 
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

Subscribe to posts via RSS

Sunday, November 13, 2011

Why do Programmers get paid less than PMs and BAs

I came across this interesting question over at programmers.stackexchange.com which asked: Given that programming is generally more difficult, why do business analysts and project managers get higher salary than programmers? What is it that makes their job a high paying job when even at most times programmers are the ones that go home late?

There were a few great answers, but only one stands out as the truth, and that is the one which is coming from an economic rationalist's viewpoint ...
People get paid less than their employers' "reservation price" (the most they would ever pay), and more than their "marginal product" (the least they would ever work for). Your actual pay on that spectrum is based on your bargaining power, relative to your employer. 
Say your services to your company are worth $1000 a day. Under the gun, he would pay you that if he had no other choice. Say you would work for $100 a day if you had no other options. That's your range. 
Say you're new and independent and unknown, and your boss is Google. Google has more bargaining power, because they can just wait and hire someone else, and lots of people want to work for them. You have less power, because you have to pay rent, so you'll get closer to $100 than $1000 a day. 
Say you're the last COBOL programmer on Earth, and your boss's mainframe runs COBOL. Then you have more bargaining power, and will get closer to $1000 a day. 
SO, either PM/BAs are worth more to the company, OR they have higher bargaining power. I don't think it's the first option, so must be the latter. Good people skills are rare. It's also hard to outsource them, as they have to meet clients. Their relative scarcity gives them more bargaining power, and thus higher pay.
This is a great answer by NRM and although slightly boring compared to the other answers which touch on the political side of things, it definitely has the ring of truth to it. As he mentions, good people skills are rare, and provide a huge benefit in any job, especially in the field of software development.

Follow @dodgy_coder

Subscribe to posts via RSS

Sunday, November 6, 2011

StackOverflow's Programming Language Bias

Using StackOverflow.com, I've always had the impression that its biased towards C#, and .NET in general. That might have been because on the SO tags page C# is number one, with the most questions tagged, or maybe because much of the site itself is built with C# and MVC.NET. So I thought it would be interesting to compare the rankings of the tag popularity on StackOverflow with a leading language popularity index (the TIOBE index).

Method
The "Stack Overflow Representation" represents a ratio of the SO tag count (as a percent of total questions) divided by the TIOBE language index percent. Where a representation of 100% means that the SO tag count is aligned exactly with the TIOBE language index. An "over-representation", greater than 100%, might mean there's a greater number of questions on SO than we'd expect. An "under-representation", lower than 100%, might mean there's not as many questions on SO than we'd expect.

Results
Suprisingly, JavaScript came out to be the most "over-represented" language on SO, by quite a long way at 294%. Could this also be because programming JavaScript is generally quite difficult and will result in people seeking help more often? Following this was C# (which I had expected to be number 1), at 153%. After this, PHP, Ruby and Python were basically fairly balanced at around 100%. The most "under-represented" major language would definitely be C at 11%. Three other major languages which seemed to be a bit under-represented, below 50%, were C++, Java and Objective-C.


Data Sources: