Wouldn’t it be nice if code grew on trees?  So whenever you need to create an e-commerce system for a client, you could step outside to your little “code patch” and pluck a payment gateway solution.  Or maybe on the weekends, head over to the Codefarmers Market and pick up a bushel of contact forms, some ripe Analytics modules, and a URL-rewriter or two.

But until that day, it’s a great idea for developers to set up and maintain some sort of “code bank.”  Anytime you come up with a useful snippet, class, function, whatever — document how and what it does and store it in an easily accessible location where your colleagues can use it.

Benefits of Your Own Repository

I’m willing to bet that a well-formed Google search serves as your “code bank” most of the time, and yes the Internet can be great, but there are some benefits to maintaining an internal repository:

You manage the contents

The only things in your code bank are items you or your development group have deemed worthy of reuse.  This will save you time sifting through sites like CodeProject or forums looking for applicable examples.  Not to mention the millions of search-engine hits.  Maintaining your own code bank keeps your code relevant.

You manage the composition

By far the most important benefit, you decide how the information is saved.  Is it searchable?  Will there be use-case examples?  Are they simply text-files you wrote in Notepad and stuffed in an FTP folder?  Determining how the code bank is structured ensures your code is usable.

Construction of a Repository

So we know it’s a good idea to have a code bank, but how do we make one?  I won’t go into specifics here, since there are many available platforms such as revision control software (CVS, SVN, Git), snippet databases like CodeBank, mind-mapping like FreeMind, or even using a CMS like WordPress with tagging.  However, I will highlight some of the basics you may want to consider when building your repository:

1. Informative: Copy-Pasting a block of code to a text file in a folder labeled “Code Bank” may be quick, but what happens when you come back to it in a week?  In a month?  When your replacement sits down at your computer?  Even though it takes more time up-front, you will thank yourself for completely documenting your code, both inside the snippet and with some sort of external metadata.  This could be an associated help file, some real-world examples, a blog post with tags describing the code, or commit comments.
2. Searchable: The difficulty of satisfying a specific need may or may not increase as you start to accumulate items in your repository, depending on how well you organize your code hierarchy.  This is where the metadata can be particularly useful, as it adds to the “searchability” of your code — using things like tagging or keywords, content-relevant titles and summaries, etc.  This concept isn’t a new one, for example, search engine optimization uses similar practices. When your site gets indexed by search engines it uses the meta data as a starting point: title, description and keywords. There is always more than one way to do something, you just want to make sure it’s the best way.
3. Available: You may have the best repository ever, a holy-grail of snippets — but if you’re the only person with access, so what?  Placing your repository on a shared network drive, on a local server, or a public web forum all help to distribute your accumulated knowledge.  In turn by making it available those code snippets can only get better with more exposure and re-use. Of course, if you are developing proprietary information, then make sure to include the proper safeguards.
4. “Backupable”: Like number three, you may have done everything right, setting up a code bank on par with Google…until your harddrive crashes.  I know this one is obvious, but I cannot stress the following enough — if it doesn’t exist in at least three places, it doesn’t really exist at all.  Possibly the “Platinum Rule” of computing.  If you have set up your repository on a local server to increase availability, it may already perform regular backups.  Storing local copies of the code (like in SVN) can help, as at least someone will have some version of the repository somewhere.  Even emailing yourself a zip-file of the repository is better than nothing at all.

A programming repository will help to cut down on the time you and your development team spend on common tasks.  Creating and maintaining your own code bank will ensure that the code is relevant and usable, as long as you set it up in the first place to be informative, searchable, available and regularly backed-up.  Now only if it earned interest too…