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

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

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 on Twitter

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:

• Stack Overflow data taken from: StackOverflow.com/tags - data snapshot taken at 2:50am UTC, 6-Nov-2011. Total tag count was 2,254,639.
• TIOBE data taken from: latest available (October 2011) at www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Follow @dodgy_coder

Subscribe to posts via RSS

How to Become a Better Programmer

Here then, in no particular order, are twelve positive things that you can do, at any point in your career, to improve your programming skills. These will also have the added benefit of injecting additional passion into your programming ...

1. Never Stop Learning and Reading

Consciously try to improve yourself and the quality of code you write. Think about what you're doing, why you're doing it, and how you can do it better.  Look back at what you've done on previous projects, and how you might do it differently now, or where you could still improve on it.

• Read books, not just websites.
• Read for self-improvement, not just for the latest project.
• Read about improving your trade, not just about the latest technology.

2. Work With People Smarter Than Yourself

Working with smarter and/or more experienced developers will teach you a great deal. You can learn a lot by reading their code, watching their practices and listening to their opinions and stories. Also, you should always listen to what others have to say, regardless of whether they're junior, intermediate, senior or guru-level developers.

3. Become a Polymath (or 'Jack-of-all-Trades')

Decide to be a 'Jack-of-all-Trades' - also known as a Polymath, Polyglot, Generalist, Renaissance Man or Multi-specialist. This will allow you to avoid becoming 'pigeon-holed' into one specialty, which can stagnate your programming skills, as well as hurt your future employment prospects if your 'specialty' suddenly becomes yesterday's technology. Something to keep in mind is 'the half-life of knowledge' law of technology; it tracks with Moore's Law: half of everything you know will be obsolete in 18-24 months. An expert who chooses the wrong discipline can easily be undermined by the press of technology; a generalist only has to add some more skills and remember the lessons of the past in applying those skills.

4. Read and Document Other People's Code

Read and attempt to understand code written by others. Plus, write documentation for code written by other people. Writing code is significantly easier than reading someone else's code and figuring out what it does. You can see how they do something - maybe they do it in a better way than you. And sometimes this can be one of the best ways to learn how not to do something.

5. Get Programming Experience on a Real Project

There is nothing like getting in and coding, especially under pressure - work on a real project, with real fickle customers, with real, ever-changing requirements and with real engineering problems.

6. Teach Others About Programming

Take a part-time job tutoring computer science students at a local university or college. This will force you to understand something at a completely different level,  since you have to explain it to someone else. As Douglas Adams wrote, "the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas."

7. Learn One New Programming Language Every Year

One year gives you enough time to get past the basics - it pushes you towards understanding what's beneficial in that language, and to be able to program in a style native to that language. Each language will change the way you think about programming, and how they do things, to compare that to what you already know.

8. Complete One New Pet Project Every Year

Start a "pet" project and follow it to completion and delivery. A good pet project will push your boundaries and keep you interested; it may be something you have experience with and enjoy plus something you don't know about. E.g. if you know something about game development but don't know Ruby, a good pet project may be to develop a game written in Ruby.

9. Learn Assembly Language

Learning a low level language like assembly gives you insight into the way computers 'think' without any high-level abstractions; the elegance at this level is surprising. There are no wasted motions, no disposing of data, and bugs can have a far greater impact. Developing at this level will teach you efficiency and hone your critical thinking and logic skills.

10. See Your Application From the End User's Perspective

Step out of the echo chamber and improve your understanding of the end-user aspect of software development. Interact with the end-user to see, through their eyes, how they use your software. End users are typically not technical, and they often see software as a magical piece of work, while you see software as a logical set of steps. The two worlds are completely different - what seems easy and logical to you may seem cryptic and inscrutable to others.  You can also find out what kind of 'abhorrent' information they throw at your application. This will help you generate good test cases and stop assuming your program will always be fed the correct set of data.

11. Start a Physical Exercise Program

You work a whole lot better when you're in good physical shape - problems become easier and less overwhelming, wasting time is much less of a temptation, you can think clearer, and working through things step by step doesn't seem an arduous task. An old one but here it is: "Sound body, sound mind.". Regularly devote a bit of time to physical exercise - riding a bike, walking, running, swimming, whatever suits you best.

12. Learn Touch Typing

Typing for a programmer is essential. Everyone has had a coworker who typed using just two fingers and had to look at the keyboard for everything before pecking out their code one letter at a time! Learning to touch type is a quick and effective way to give your productivity a boost as a programmer.

Follow @dodgy_coder

Subscribe to posts via RSS