Old bag of tricks

Meta

The main reason for starting this blog was to serve as an incentive to do some long-overdue tidying. Like pretty much any programmer who’s been working for a few years, I’ve got a little bag of tricks I’ve been carrying around throughout my career (17 years so far, of mainly C++, Delphi, and C#). Over the years, some bits and bobs have become obsolete (like that string class I wrote back in 1993, and everything I’ve ever written in Visual Basic), others have been lost in transitions and moves, but it’s still a sizeable bag.

Most of the things in the bag, though, has been unorganised little snippets of code, random functions and classes that have been half-formed, often neither tidy or documented enough to be presented publicly. Some has come from experiments and trials, some from various hobby projects, and some from times my work contract has given me some rights to the software I write.

The last part there is a sensitive area. In most employment contracts, the employer retains the full right to the code you write as part of your job. If you are an independent contractor, the rights issue can be more flexibly negotiated, and there’s sometimes a distinction made between business-related code, and supporting code.

In most cases, the code I’ve written in my day job is code I have no rights to. But because I’m a geek, I’ve sometimes thought “Oooh, that’s interesting”, and sat down to try out and experiment with some concept in my spare time. In those cases, the inspiration might have come from my day job, but the code has been written in my spare time, from scratch. It may be because I’ve wanted to learn more, or because it’s been an interesting problem to solve, or simply because the day job has only required a partial, specialised solution, so I’ve wanted to do a full solution for my own intellectual satisfaction.

It’s often been the case, too, that I’ve found a use for these little snippets later, for a different employer, and in those cases I’ve taken my old code and tweaked or rewritten it to fit into the style and needs of the current workplace.

So I finally decided to tidy things up. I’ll be re-visiting my old code folders, and extract what’s useful or interesting, and tidy it up, and package it. I will:

  • stick to a single style of coding (per language) and rewrite the code to have a consistent look
  • organise the code into namespaces and classes
  • comment the code thoroughly
  • use Doxygen or similar to extract the comments to useful documentation
  • write a simple test app to exercise the code for each module
  • for each module, create packages with:
    • only source code
    • source code, documentation, and example/test app
  • release under a BSD license

Why? Well, in a large part to make it easier for me to find, and introduce at the places I work. And I also think other people might find these bits and bobs useful.

I wonder, though, whether it would also be useful to make the code available on SourceForge and/or CodeProject?