Top 25 Most Dangerous Programming Mistakes

http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html

Summary article listing the 25 most dangerous (in terms of security impact) programming mistakes. Even if you’re aware of all of these, it’s worth re-familiarizing yourself (and your co-workers) with them.

Microsoft runs fuzzing botnet, finds 1,800 Office bugs

http://www.computerworld.com/s/article/9174539/Microsoft_runs_fuzzing_botnet_finds_1_800_Office_bugs

No, not that sort of botnet. Microsoft are using a distributed computer system to generate random changes to Office files, in an attempt to discover buffer overruns and other vulnerabilities in the file format parser.

Much ado about NULL: An introduction to virtual memory

http://blog.ksplice.com/2010/03/null-pointers-part-i/

Down-to-the-metal article explaining pointers, memory mapping, and virtual memory. Worth reading as it covers the basics that we rarely think about.

Amazing feats of Clang Error Recovery

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

Clang is the new up-and-coming C/C++ open-source compiler. If you’ve ever worked with C++, you’ll know how cryptic and downright useless the error messages emitted by most compilers are. Clang is attempting to address that weakness.

Good Math, Bad Pointer Math / C Is Not Assembly

http://james-iry.blogspot.com/2010/04/good-math-bad-pointer-math.html
http://james-iry.blogspot.com/2010/04/c-is-not-assembly.html

A deep-dive into the intricacies of C pointers, and how they relate to the C standard. If you’re interested in writing portable and correct C code, this is worth a read.

Underscore.js

http://documentcloud.github.com/underscore/

Not so much an article as a useful download – Underscore.js (named after the identifier used to access the functions) provides a suite of functional programming constructs for JavaScript.

What’s wrong with extending the DOM

http://perfectionkills.com/whats-wrong-with-extending-the-dom/

JavaScript allows any objects to be extended, either on a per-object or per-type basis. The popular Prototype library used this mechanism – and subsequently found it to be a bad idea. Prototype 2.0 is moving away from  this technique – read this article for a clear explanation why.

The ASP.NET Web Development Horror

http://www.codingthewheel.com/archives/asp-net-web-development-horror

I’ve recently started (belatedly) playing with ASP.NET MVC 2, and it’s a breath of fresh air compared to “classic” ASP.NET. (Presumably “classic” ASP is now “classic classic ASP”). If you’ve not been able to articulate why ASP.NET wasn’t up to scratch, this well-written and funny article will help. How can you not read an article containing the phrase “tricksy little hobbits doing obscene things in the cupboards”?

Use C# dynamic typing to conveniently access internals of an object

http://igoro.com/archive/use-c-dynamic-typing-to-conveniently-access-internals-of-an-object/

I’ve linked to Igor’s blog before – the articles are clear, well-written, and well-laid-out. This article suggests a new use for one of .NET 4.0′s new features, dynamic types.

A Brief, Incomplete, and Mostly Wrong History of Programming Languages

http://www.cvaieee.org/html/humor/programming_history.html

I like to end on a light note, so here’s a couple of funnies. If you’ve ever wondered about this history of various programming languages, this article is completely incorrect.

First among SQLs

http://www.theregister.co.uk/2010/04/20/verity_stob_sql/

If you’re ever bored at work, you can do far worse that read Verity Stob’s collection of articles. They’re tongue-in-cheek, deadpan, and scarily accurate.

Microsoft turns 35: Best, worst and most notable moments

http://www.computerworld.com/s/article/print/9173238/Microsoft_turns_35_Best_worst_and_most_notable_moments

An interesting look back at Microsoft’s history. Love ‘em or hate ‘em, you have to acknowledge the mark they’ve made on the IT industry. You’ll almost certainly know everything in this article, but it’s a nice summary all the same.

Windows Phone 7 Series: the complete guide

http://www.engadget.com/2010/03/18/windows-phone-7-series-the-complete-guide/

The details of Microsoft’s upcoming mobile OS were released recently, and this is a nice summary article. The graphical appearance of the OS looks very fresh and modern – could Microsoft have turned a corner, design-wise?

Building a Windows Phone 7 Twitter Application using Silverlight

http://weblogs.asp.net/scottgu/archive/2010/03/18/building-a-windows-phone-7-twitter-application-using-silverlight.aspx

Given the familiarity of the coding environment for Windows Phone 7, I could be tempted to wish for one, instead of wishing for an iPhone.

Programming Windows Phone 7 Series

http://www.charlespetzold.com/phone/

If like me you like to read an old-fashioned book in the bath instead of reading articles on-line, Charles Petzold is preparing one. Here’s a sneaky preview in PDF format.

New, But Not So Obvious, Features in .NET 4.0

http://galilyou.blogspot.com/2010/03/new-but-not-so-obvious-features-in-net.html

.NET 4 is with us, and there are plenty of new, headline features. Here’s a few that barely get a footnote – but which are interesting nonetheless.

Hello from a libc-free world! (Part 1)

http://blog.ksplice.com/2010/03/libc-free-world/

Why would a single-line program produce a larger-than-expected executable? Where does that excess baggage come from? And if you wanted to ditch the standard core libraries, how would you go about it?

Visualizing Usage of the Firefox Menu Bar

http://blog.mozilla.com/faaborg/2010/03/23/visualizing-usage-of-the-firefox-menu-bar/

Interviews with Average Programmers

http://blogs.citytechinc.com/sanderson/?p=290

I’ve been reading “Coders at Work” recently, a collection of interviews with great programmers. What would an interview with a coder like you or me be like?

5 Stages of Programmer Incompetence

http://coderoom.wordpress.com/2010/03/19/5-stages-of-programmer-incompetence/

Tongue-in-cheek article (mostly) about how we progress in the craft of coding. I can recognise aspects of myself in all of these.

A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World

http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext

This article is kind of an advert for Coverity, but it’s interesting all the same. It’s partly about their static code-analysis tool, but mainly about the social aspects of selling the software.

A Big Case of …OOPS…

http://www.communities.hp.com/securitysoftware/blogs/rafal/archive/2010/02/25/a-big-case-of-oops.aspx

Is defense against SQL injection attacks important? Absolutely, but for a middle manager it’s probably an academic issue… until you see your site has been hacked, right in front of your eyes.

Hg Init: a Mercurial tutorial

http://hginit.com/

Joel Spolsky might have stopped blogging, but he’s still writing other kinds of articles. This is an excellent introduction to Mercurial, a distributed version-tracking system. OK, so you might be stuck using Visual SourceSafe at work, but a coder can dream.

Processing.js

http://processingjs.org/

I’ve always fancied playing with Processing, the Java-based graphical environment, but the Java aspect always put me off. This is a JavaScript version, so anyone can view your creations.

Home-baked graphics

http://bit-player.org/2010/home-baked-graphics

In these days of pre-packaged charting libraries, it’s refreshing to see someone getting down to the metal (LISP and PostScript, in this case) to generate custom graphs. Why does the author bother? And where to go from there? Read for a discussion.

Prefer Futures to Baked-In “Async APIs”

http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=222301165

Very useful, very specific, and practical article about a better technique for writing APIs that expose concurrency. Recommended reading despite Dr Dobb’s in-your-face adverts and pagination.

Comet with node.js and V8

http://amix.dk/blog/post/19484

A presentation (slideshow, no audio or video) on node.js, a JavaScript web-server running on Google’s V8 engine. Very interesting concept – using an event-based system vastly simplifies the code needed to serve data. There’s plenty of discussion about node.js on the interwebs at the moment – hopefully it will grow and become more than just a curiosity.

Gallery of Processor Cache Effects

http://igoro.com/archive/gallery-of-processor-cache-effects/

Interesting blog post about the effects that processor caches may have on performance. Examples are in C#, but really apply to any language.

Microsoft’s Creative Destruction

http://www.nytimes.com/2010/02/04/opinion/04brass.html?pagewanted=1&ref=opinion

Opinion piece from the NYTimes regarding Microsoft’s recent lack of innovation (at least, in the area of shiny gadgets). Written by an ex-vice-president of Microsoft.

How Many Passes?

http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

Summary article from Eric Lippert describing the differences between the C# compiler and a “traditional” compiler, and listing the various passes made over the symbol tree.

A Deadlock Holiday

http://www.theregister.co.uk/2009/12/10/verity_stob/

Very funny tongue-in-cheek article about the current state of parallel / multicore coding techniques, from Verity Stob of The Register.

A Maturity Model for Source Control

http://lucas-ward.blogspot.com/2010/02/maturity-model-for-source-control-scmm.html

Semi-opinion piece assigning levels to types of source-control systems – from “No SCM” through “Clunky” to “Speedy, Invisible, and Highly Capable”.

Luckily, that is now changing with the recent release of .less (Dot Less). This is a port of the Ruby LESS library to .NET. It’s still in beta, so be warned that the API is still in a certain amount of flux. (That’s a good thing however – I’d rather have a bit of pain in the beta stage, in return for a well-thought-out API later on). The authors are very responsive – there’s a friendly discussion group – and the couple of bugs I’ve reported have been fixed within a very short time frame. This project seems to be in very active development, and I’m extremely impressed with it. It’s so simple to use, and gives CSS development a much-needed shot in the arm, that using this library seems a no-brainer decision to me.

So what benefits does this library give you? (Examples are taken from the .less homepage).

1. Minification

The final output from .less is a compacted (or minified) version. This means you can write your CSS with as many comments and whitespace as you like, without worrying that the client-side download will be huge. This might seem like a “meh” feature, but it’s free and will have immediate beneficial effects on your bandwidth.

2. Variables

CSS doesn’t support any form of variables or macros, so constants (the worst culprit being colours) get copied around the CSS file. That’s fine until you decide that the pink-on-orange colour scheme isn’t working, and you need to make a change. .less allows you to define variables using the syntax “@name: value”, and then reference them anywhere a value would otherwise be used.

Example:

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

3. Mixins

We’re now in a second round of “browser wars”, with modern browsers providing useful features such as border-radius via non-standard extensions. We also have to cope with Internet Explorer still making use of odd syntax for features such as opacity (via filter). The upshot of this is that to define certain CSS effects, we have to provide three or four CSS style properties, to cover various browsers. Mixins allow this bloat to be ameliorated by defining a class with the desired properties, and then “mixing” them into another class.

Example:

.rounded_corners {
  -moz-border-radius: 8px;
  -webkit-border-radius: 8px;
  border-radius: 8px;
}

#header {
  .rounded_corners;
}

#footer {
  .rounded_corners;
}

4. Nested Rules

This feature is probably of least interest to me, since I favour single-line rule formatting, however if you write multi-line rules, then this could be a very useful feature. Nested rules allow “inheritance” of CSS rules, such that more specific rules may be nested within a less-specific parent rule.

Example:

#header {
  color: red;
  a {
       font-weight: bold;
       text-decoration: none;
    }
}

I could possibly see myself using it for :hover rules and the like.

5. Operations

Since I’m merging .less into an existing codebase, I haven’t yet refactored my CSS to make use of this feature. Operations allow arithmetic to be performed on expressions involving variables. For example, instead of defining variables for a colour and its lighter equivalent, you can instead just define a variable for the colour, and then computer the lighter colour.

Example:

@the-border: 1px;
@base-color: #111;

#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}

#footer {
  color: (@base-color + #111) * 1.5;
}

Alternative Usage

The homepage gives instructions for a quick-up-and-running scenario, however I already had code to handle caching and combining of stylesheets, so I wanted to hook into that. It’s easily possible to process CSS as strings if desired:

// .less format CSS as string in 'input'.
var dotLessEngine = new dotless.Core.engine.ExtensibleEngineImpl( input );

// Transformed CSS now in 'css'.
var css = dotLessEngine.Css;

// Now minify...
var dotlessMinifier = new dotless.Core.minifier.Processor( css );

// Output CSS suitable for sending to client in 'output'.
var output = new string( dotlessMinifier.Output );

Smart, and Gets Things Done

Joel Spolsky’s 2006 article “The Guerrilla Guide to Interviewing” is a real classic that’s since been made into a book. He argues that there are two things to look for when interviewing, and that a candidate needs to have both attributes – having just one is as bad as having neither.

“Everybody gives lip service to the idea that people are the most important part of a software project, but nobody is quite sure what you can do about it. The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmers are, and this is usually done in the interview process.”

Read Joel’s Article: The Guerrilla Guide to Interviewing (version 3.0)

Done, and Gets Things Smart

Steve Yegge’s 2008 response article reminds us that recognising smarts (in ourselves and others) isn’t even necessarily possible. He suggests that the best approach to hiring is finding “seed” employees (although obviously being able to identify them is a Catch-22 situation). To find them you either need to be lucky, or perhaps home in on them via word of mouth.

“How do you hire someone who’s smarter than you? How do you tell if someone’s smarter than you? This is a problem I’ve thought about, over nearly twenty years of interviewing, and it appears that the answer is: you can’t. You just have to get lucky.”

Read Steve’s Article: Done, and Gets Things Smart

(I’m going to use C# in my examples here: some of these points might not apply to all languages. By default, an assertion will not fire in a C# release build, and furthermore, the code inside will not even be executed).

Update 2009-06-11: I probably haven’t been clear enough, but luckily various commenters have picked up on this: I’m not advocating removing assertions and replacing them with nothing! In general, I think assertions should be replaced with a stronger check that also runs (or can run) in a release build.

1. Pointless Guard Checking

Unfortunately in my coding travels I see quite a bit of code like this:

void Foo(Bar bar)
{
  Debug.Assert(bar != null);

  bar.DoSomething();
}

What’s the point? If bar is null, then using it will throw an exception anyway. Why add unnecessary lines of code that make reading harder?

2. Bad Argument Checking

But, you’re thinking, what if the usage is separated from the assignment?

class Foo
{
  public Foo(Bar bar)
  {
    Debug.Assert(bar != null);

    _bar = bar;
  }

  public void Method()
  {
    _bar.DoSomething();
  }

  private Bar _bar;
}

True, you want to catch the error as it happens, not later on in the method. But shouldn’t you be throwing an ArgumentNullException instead?

3. Difficult Detective Work

So now you’re telling me that you’re not writing component code, and the only client of this class will be the application it’s embedded in. Why not save some effort and skimp on the checking code, and make it debug-only?

Fine idea… until you get a crash report from one of your users, and the stacktrace points to a NullReferenceException in Method(). Now you have to figure out where the null value got passed to the constructor… a potentially much more difficult task.

4. Differences Between Debug and Release

If you’re like me, you generally run the applications in debug. Your customers however, run in release. Why make the differences between these two versions any bigger? Even if you don’t intend your debug statements to change program state, it’s all too easy to accidentally do so:

• Running lazy-initializers or singleton constructors;
• Loading data from the database via an ORM;
• Moving data in or out of a cache;
• Running static constructors.

5. Too-Shy Sanity-Checking

Sometimes, despite the above warning, you really do have sanity-checking code that you’d like to run in a development or test environment to catch regressions, but which is too slow to give to general users. (I read somewhere that Excel has two computation engines: a simple, slow, reference one, and a fast, parallel, release one. Testers can run the two in parallel, and any differences are automatically flagged as errors).

So you might be tempted to do something like:

Debug.Assert( SlowlyAndCarefullyVerifyInternalState() );

The problem I have with this is that the debug/release division is way too blunt.

• Suppose a tester wants to test a release build, but also perform the sanity-checking?
• Suppose a customer finds a bug in a complex calculation, and you want them to run the checks?
• Suppose a developer wants to debug performance issues in the non-checked code?

I would suggest you move the conditionals for code like this to a (possibly hidden) configuration setting. Someone wants to run in slow-and-safe mode? No problem, just tell them the registry setting (or whatever). By all means, change the splash screen or title bar or whatever so it says “test mode”.

The advantages of this method are:

• Anyone can turn it on and off;
• Sanity-checking can be controlled at a much finer granularity than all-on / all-off.

6. Is It Recoverable, Or Not?

The final argument against debug assertions concerns just exactly what an assertion means.

To my mind, an assertion is different to a simple flow-control test (“did the user enter a valid number?”), which is something the program can (should) handle. By definition, an assertion is checking for a disallowed state. An assertion doesn’t check for incorrect data; it checks for an incorrect program. Continuing after an assertion leads to undefined behaviour.

So how can you continue? More to the point, why should a user even be allowed to continue? If the state really is unrecoverable, then fail. Fail fast, log the error, and bail (possibly trying to allow the user to save work, or whatever). Having a release-build application continue after what would have been an assertion is just plain wrong.

The problems we’ve experienced following installation of IE8 have been:

• Windows Explorer opens folders in new windows, even if you have “Open each window in the same folder” checked;
• “Open in new tab” doesn’t work in IE8;
• Can’t connect to databases using SQL Management Studio Express 2008 (“Unable to cast COM object of type ‘System.__ComObject’ to interface type ‘Microsoft.VisualStudio.OLE.Interop.IServiceProvider’. Exception from HRESULT: 0×80004002 (E_NOINTERFACE)”).

The solution is pretty simple:

1. Go to Start -> All Programs -> Accessories, right-click “Command Prompt”, and choose “Run as Administrator”.
2. OK the user access warning dialogs.
3. Enter “regsvr32 actxprxy.dll”.
4. Reboot.

Sorted! No more tearing my hair out.

1. Use a Reset Stylesheet

Different browsers are free to set default styles for font sizes, margins, and so forth. It’s a silly part of the specification but there you go. Rather than trying to eliminate these differences on a case-by-case basis, many web developers now make use of a reset stylesheet to set all margins to zero, remove all borders, standardize all font sizes, and so forth.

There’s dispute over which particular features need to be reset; but to be honest having any one of them is going to be better than none. Here’s a few examples:

• Eric Meyer
• Yahoo!
• Crucial

2. Use a Browser Development Plug-In

When you’re learning it’s useful to be able to visualise “invisible” parts of your web-page – margins, padding, parent positions, and so forth. Unless you fancy setting debugging background and border styles, or guessing why your functions stop half-way through, I’d recommend getting a web development plug-in for your browser.

Most plug-ins will let you dig trough your DOM, debug JavaScript functions, and provide statistics about document load times.

• Firebug – plug-in for Firefox. This is an absolutely fantastic and invaluable tool for web development.
• Yahoo!’s YSlow – plug-in for the Firebug plug-in. Analyzes web pages and tells you why they’re slow.
• Internet Explorer Developer Toolbar – plug-in for Internet Explorer. It feels like it was written in an afternoon by someone who had no idea what web development involves, but there isn’t really any alternative for IE.

3. Learn JavaScript

Learning JavaScript is still a work-in-progress for me. When I started web design I assumed (please note that word “assumed”!) that JavaScript was a toy language, suitable only for pointless browser effects. Boy was I wrong!

JavaScript, especially with the rise of AJAX, is becoming less an optional add-on, and more and more a vital part of modern web applications. It’s an elegant language, possibly let down by poor IDE support, and used correctly, will let you jump your browser through hoops. Imaging Google Maps or Yahoo! Pipes without it.

4. Pick a JavaScript Framework, and Learn It

Learning JavaScript is all well and good, but once you start trying to use it in anger you soon learn that each browser has a subtly different DOM API (or not so subtly different in the case of Internet Explorer).

You could re-invent the wheel and spend ages handling these different edge cases, or, I’d suggest, you could learn a framework and let it do all the heavy lifting.

Not convinced? How about this jQuery code to stripe table rows (details omitted for clarity):

$(function() {
  $('.stripe tr:even').addClass('alt');
});

(Yes I know in theory you should be able to do that in CSS. As always, Internet Explorer raises its middle finger to CSS theory).

Here’s a few links to some major frameworks:

• jQuery
• MooTools
• Prototype
• YUI
• script.aculo.us

5. Learn Photoshop

Ahhh, Photoshop. If you’ve only used simple paint programs before, using Photoshop is like emerging from a cave into the sunlight. (OK, that’s a bit of an exageration).

Traditional paint applications work on the basis that you want to change the color of pixels. Photoshop (at least for web design) works on the basis that you define regions, which are then styled. Pixels are assigned colors as a side-effect. The rules are:

• Layers are king;
• Selections are queen;
• Nothing should ever be destroyed or lost.

So as a little example, if something needs a drop-shadow, you don’t start trying to draw one. (That would destroy or change the original thing). You simply make sure the thing is in its own layer, and apply a drop-shadow style.

6. Use Semantic HTML – And No Cutting Corners

Web design usually starts with graphic design, but really it should start with the content and proceed from there. If you start with the visuals, it’s all too easy to fixate on why things don’t look right, and from there it’s slippery slope to using non-semantic elements and inline styles.

Start with the content; use appropriate elements without regard for style; and only once you’ve done that should you move on to writing an appropriate stylesheet. (Of course, you may sometimes need to add stylistic divs… although you’d be better off using JavaScript to modify the DOM, rather than modifying the source itself).

A corollary of this point is that tables should only be used for tabular data – there’s no usual need to use them for layout.

7. Find Out Why It Doesn’t Work – Don’t Shotgun-Debug

The HTML/CSS visual model is pretty complex: inline vs block elements; different position modes; and so forth. What makes matters worse is that there’s no definitive reference HTML renderer implementation: you can never be sure whether your page doesn’t look right because you’ve made a mistake, or whether it’s some browser bug.

This state of affairs can lead to shotgun-debugging: tweaking a value to see if it fixes the problem; tweaking another value and checking again; and so on and so on…

Obviously this way of learning isn’t ideal. If you ever want to learn, I’ve found that you need to be predicting the effects of your changes. Before you make a change, you should have an idea in your head of the expected effect. If the actual effect isn’t the intended effect, you need to find out why. Is your understanding of HTML/CSS wrong, or is it a browser bug? Test on more browsers, and if your understanding is wrong, correct it. (Of course, if it’s a browser bug, then you’ve learnt something afterall).

8. Test on Internet Explorer Earlier

You might have noticed from my snide comments about Internet Explorer that it’s not exactly my favorite browser. If I’m going to be fair, IE7 isn’t too bad, and IE8 promises to actually be standards compliant (gasp!). What bugs me is that (at the time of writing) about 30% of the world is still using an eight-year-old browser that doesn’t even get the basics of the HTML box model correct, and we web developers are expected to support it.

Anyway… I didn’t intend this paragraph to be a rant, so deep breath… and… we have to live with the situation as it is. Firefox has great standards compliance and great developer tools, so it’s tempting to use it as your primary development platform until right at the end, when you do cross-browser testing.

Don’t do this. I’ve learnt the hard way: you need to test your work at each stage, on all browsers. Even as recently as six months ago I was caught out by this: I spent a lot of time coding some web code that relied on z-indexing, only to discover that IE7 doesn’t support this feature fully. In the end I was able to bludgeon Internet Explorer into working properly with some JavaScript, but it wasn’t fun. Lesson learned: check each feature is going to work properly on IE before coding it completely.

9. Don’t Be Afraid of AJAX

Normal web-pages are pretty easy to understand. The browser makes a request; the web server sends back some HTML. AJAX is a little more difficult to understand, so I steered clear of it for two years.

I finally got stuck in when we started writing EasyAs123Web.com. I wanted the user to be able to edit the website in-place, so that forced the issue.

When you get down to it, AJAX is pretty simple.

1. User does something (eg clicks) in the browser;
2. JavaScript makes request to server (in a thread);
3. Server replies with an XML document describing what to do;
4. JavaScript received the reply and modifies the DOM based on that XML.

Of course, the devil is in the details, but a decent AJAX library hides most of that for you.

10. Charge For Old Browser Support

Asking a client if they need Internet Explorer 6 (or earlier) support is a recipe for extra work. They’re hardly going to say no when you phrase it like that. You then sit down and make a working website, and test it in IE6. Argh! Scrambled website! Eventually, you get it working, and you find that you’ve spent twice as long on the actual HTML/CSS as you planned to. Bad times.

Here’s my suggestion: treat older browser support the same as any other feature: as a chargeable item. Explain to the client that since older browsers work in a different way to modern ones (which they do), that’s extra work and hence extra cost. (I’d suggest approximately 10% on top). Explain that IE6 has approximately 25-30% market share, and let them make the cost/benefit call. Money has an amazing focusing effect: it forces people to really think about what they want and need.

Your Thoughts?

Got your own web development tips? Feel free to share them below!

Introduction to Abject-Oriented Programming

Judging by the comments posted, only about 50% of people even realize it’s a joke – it’s worth reading through them for a second laugh.

Some notable quotes:

“Programs that use inheritance are characterized by similar blocks of code with small differences appearing throughout the source.”

“Abject-oriented programming lends itself to using plug-in components — bits of code found in books or on the Internet.”

“A virtual class or function is code that the application will eventually need, but it isn’t written yet.”

Which brings me onto cargo-cult programming. If you haven’t heard that term before, it usually refers to pacific islands, visited during the second war by much more technologically-advanced societies (e.g., the US), generally to establish military bases. Of course, after the war, the ships of the more advanced civilization stopped visiting the islands. A cargo-cult religion, not understanding the wider picture, tries to bring back the visitors by the use of rituals and making replicas of the technologial artifacts the covet. (More info on Wikipedia).

Anyway. Enough sounding like a lecturer. Cargo-cult programming is a similar sort of thing, where the “programmer” wants to achieve a particular effect, but can’t or won’t work out the details for themselves. Unfortunately the rise of the search-engine has exacerbated this problem – it’s just too easy to type in a few keywords, find a snippet of code, and paste it into the project you’re working on.

It’s an easy trap to fall into – as an example, my JavaScript skills are pretty weak at the moment, but the project I’m working on at the moment needs a fair amount off client-side coding. It’s so tempting just to paste in functions that seem to work. Given that I’ve been using JavaScript for less than a couple of months, learning it (and the DOM) sometimes feels like an insurmountable hill.

In the end of course, if you want to be able to call yourself a programmer, you have to understand what you’re doing, even if that means the project takes longer. It pays dividends in the end of course, but it takes discipline and an amount of short-term pain.

If you’re still pasting in code and not understanding it, well, you’re not a programmer in my book.