Starting a personal reuasable code repository.

Question

Hi,

I've been meaning to start a library of reusable code snippets for a while and never seem to get round to it. At the moment I just tend to have some transient classes/files that I drag out of old projects.

I think my main problems are:

• Where to start. What structure should my repository take? Should it be a compiled library (where appropriate) or just classes/files I can drop into any project? Or a library project that can be included? What are the licencing implications of that?

• In my experience, a built/minified library will quickly become out of date and the source will get lost. So I'm leaning towards source that I can export from SVN and include in any project.

• Intellectual property. I am employeed, so a lot of the code I write is not my IP. How can I ensure that I don't give my own IP away using it on projects in work and at home? I'm thinking the best way would be to licence my library with an open source licence and make sure I only add to it in my own time using my own equipment and therefore making sure that if I use it in a work project the same rules apply as if I was using a third party library.

• I write in many different languages and often would require two or more parts of this library.

• Should I look at implementing a few template projects and a core project for each of my chosen reusable components and languages?

Has anyone else got this sort of library and how do you organise and update it?

Answer 1

Rule number one. If you want to use it for yourself, don't use it at work and don't work on it at work. Even under those conditions some employers will think they own it even if you worked on it during the time period (calendar time) you worked for them. Some may even be more ridiculous than that. So don't even mention that it exists.

Having said that, putting it under a BSD license on sourceforge may allow you to use it with you NEXT employer provided you clarify the ground rules upfront - tell them you're grabbing such a library and possibly that you wrote it.

IANAL - I am not a lawyer. You may want to consult with one.

I prefer to work on my stuff on my time and my machines and just never mention it. Then when companies ask me to sign one of those "we own all your stuff" I make sure it doesn't apply to stuff at home - this has required getting it amended in some cases. Even in that case, if I wanted to use the code at work I'd worry that I may lose ownership because some of those lines have been blurred.

Don't worry about reinventing the wheel. They pay you to write software. And when life really kicks in you'll have less time for hobby programming anyway ;-)

Answer 2

As Neil said, a lot of the implementation details of the answer depend on your language.

However, you make 2 very valid points:

• it's better to have the library in source code form even for compiled languages, for obvious reasons

• If you wish to retain the IP and use it outside of work, then do it 100% outside of work, license with some very permissive license. Something like the zlib license might be appropriate.

One more point though - You are better off if you make sure your employer is OK with using that code!!!. You can publish it anonymously/under a pseudonym if that permission is hard/infeasible to obtain.

Answer 3

I'd go with a lightweight approach:

• Use Git or Mercurial, possibly with Dropbox if you don't want it hosted: you want version control no matter what you're doing, and distributed version control is especially perfect if you don't plan on sharing; no central repository needed
• Save whatever you use. Don't spend time creating code because you think you'll reuse it later; wait until you're about to write it twice before you add any work. Then throw the duplicated work in there, and you'll be ready if it happens a 3rd time.
• Make a directory per language; you can't reuse Java in Python, after all

Here's one directory structure you could try:

+ src
|    + python
|    |     + emailing
|    |     |    // the source goes in here
|    |     + quick-profiling
|    + java
|    + c++
+ notes
    // This may not be your thing, but it's a convenient place for them

Answer 4

I would not be concerned only about building your own code library because there are a lot of great code/snipsets out there from quite experienced people. Your greatest asset as a programmer should not only be your snipsets, but an experience about how to organize and plan your code

Considering that, plan to build a knowledge library not only made of snipsets. Take notes from books/articles you read, smart design solutions you see. If you explore BSD projects maybe you will even have more freedom to what you reuse. At the end attach

Java, Python and C++ Boost libraries are huge. Knowing what has already been solved is almost a life learning experience. Most likely many of us reinvent the wheel sooner or later.

Think about the first time you parsed an XML file. Just take notes about the most common functions, alternatives you saw and decision you took (sax over dom?) As you learn more about programming you will see that it is good to sort your snipsets by difficulty level.

I personally use a collection of text files, folder structure and custom tagging system. I write down my decisions about how to organize things to keep things consistent. The system that will work best for you will be a mixture of experience and what makes you more comfortable. With time I see that most of my text files becomes more like a general index about their subject. If they grow too large I build a new folder based on them.

Whichever choice you take make sure that it is portable (work/home) and dynamic (adapt as you learn to organize yourself). I also insist in not thinking just in code, but notes on decisions and links to books/people/projects

Answer 5

The problem with your idea, and with the concept of code snippets in general, is that it falls down badly if your snippet has a bug in it. For the snippet approach, you will have to fix the bug in the source code of all of the applications that used the snippet. If on the other hand you build binary libraries, you simply need to fix the bug once in the library code, test it there, relink, run your app's regression tests, and you are done. This is why professional programmers abhor code snippets.