views:

220

answers:

5

I frequently code numerous experiments to test various algorithms, libraries, or hardware. All code, dependencies, and output of these experiments need to be annotated and saved, so that I can return to them later. Are there good common approaches to this problem? What do you do with your experiments after running them?

+3  A: 

http://subversion.tigris.org/

Galwegian
+2  A: 

I just have a folder which I call OneOffCode

This is a folder of just code I have written either learning a new technology trying to prove a concept etc. . . This is non production code.

I usually back it up to a jump drive and move it with me from Job to job, or computer to computer.

David Basarab
Kinda wordy. I just call mine "Test".
T.E.D.
I call my tests "test" - experiments and tests are not the same thing.
anon
+4  A: 

When I do these, they are usually project specific, so they go in a subdirectory of the project (usually named "Investigations" in my case). This gets checked into the version control system with everything else.

Results (where appropriate) go into the same subdirectory of "Investigations" as the code used to produce the results.

Al
+1: We call them "Spikes".
S.Lott
@S.Lott: "Spikes": I like it!
Al
This is what I do, as well. Except, experiments branch and back up much more than production code, which tends to lead to a mess in the version control system. Searching and checking out previous versions from SVN is quite inconvenient.
Don Reba
@Don: Thankfully, it's not too bad in bazaar (one of the reasons I changed my repository from subversion to bazaar).
Al
+2  A: 

I'm usually switching between C# and C++. So, I have a Test console application for C# and C++ in a "Sandbox" location, under source control. The console applications are both setup the same way where there is a Main which calls the test that I'm trying at that time. When I'm done I keep the old methods and comments and just clear out the Main when the next test comes about.

I don't know if it is the best, but after it is setup then it is pretty quick to get in, get the answers, get out and have it all saved for the next time.

Loren C Fortner
+2  A: 

At a prior job we had a project in SVN called Area51 where people would write test code. The rules were

  1. create a package namespace
  2. start via a public static void main
  3. add comments via javadocs
  4. leave the project in a compilable state
  5. the project can never be a dependancy of other code

On a three person team this worked out ok. We could put "what if" code there to share and it was easy to run it via ide or command line

sal