How Do You Store Your Previously-Written Code?

Asmor asks: "I'm a novice programmer who is largely self-taught. It's never been too much trouble for me to reinvent the wheel constantly before, but now as my ambitions get loftier I'm finding that I could really benefit from maintaining some oft-used code that can easily be reused. The problem is, I really don't have any experience with this and I'm not really sure how I should organize things, how the code should be stored, how it should be implemented, etc. I think this is what people mean when they talk about libraries and/or APIs, but not really sure. I'm specifically curious about PHP and JavaScript, but advice for other programming languages is also helpful! How do you store and maintain your most frequently used code?"

Comments

Old code

[SysKoll]

I have code I wrote 15 years ago in an "archive" dir in my home directory, subdivided by projects.

Whenever I change my main machine, that dir is of course copied to the new one, and included in the backups. Organiwing the libraries by functionality and language would be a nice thing, but I never seem to find the time.

Beware, though: Most employers specify that code written by employees belongs to the company. If you write code as a corporate employee and then leave your employer, you should really think twice before carrying that code with you. If your new boss thinks you are copying code written in a previous job, he would have to throw the book at you.

Gmail.

[JohnnyLocust]

I just use 7zip to archive my nighly builds, and email them to myself on my gmail account. I put the comments on the code in the message body. Gmail gives you over 2.5 gigs of storage space, and you can search you message bodies and headers. I can also retrieve my code and projects from anywhere in the world, and don't have to worry about hard drive crashes.

two issues here

[blue_adept]

One issue is code re-use.
Code re-use is why you write API's and create your own libraries, so that you don't have to keep re-inventing the wheel.

The other issues are version control, code management, etc. Some ppl here are recommending cvs and other such overkill. If your a novice PHP coder, none of that matters; you probably have a handfull of scripts that weren't written with re-usability in mind, and therefore are minimally reusable (written in a language that doesn't encourage re-usability to boot) so theres no "tool" that will magically let you squeeze the juice of re-usability from stone.

At this point, you biggest concern should be storage for sake of making frequent backups. Personally, I encrypt whatever folder I'm working in (using PGP) and email it to my gmail account every day. That way it's accessible no matter where I am, and pretty secure too.

CVS beats Subversion in my opinion

[slashbart]

Hi all

Considering all the praise we read about Subversion, and its compelling features list, we switched a medium size project (80000 loc) from CVS to SVN. All in all we are not impressed with Subversion, and are not going to use it for new projects (for the forseeable future).

The bad things:

svn import: oops, there is a some experiment data in the directory, or an AAP subdirectory. Shit, the repository has grown by another 100 MB. No way to get it out again, unless you convert the whole BDB database to text, find your accidental additions, cut it out, rebuild the database, do svnadmin recover, fix all the permissions.

Really wrong error messages.

svn add *
svn rm *.log (oops added some test runs)
svn commit

" unable to get lock on file blabla". You'll now have to manually do svn rm ... on every file you accidentally added. The only way to know which ones, is by committing and waiting for the error.

Big errors:

Having moved our repository to another server, we have had situations where a subdirectory was pointing to the new server, and its parent to the old server. When we did an svn update in the subdirectory, the updates would not happen and no error whatsover was given. Worse, to prevent this kind of problems, we had renamed the repos directory on the server, so that there was no way some dangling old links could accidentally access it.

Adding files to a repository from multiple places around the lab has gotten us often into troubles

The Berkeley DB format keeps changing. You can't just copy one to a server with a slightly different svn version. Worse: it will not tell you that there is a version difference, it will just try, and come up with the most irrelevant error messages.

All in all, we find SVN not ready for prime time. Its promises are great, but at least CVS is just working reliably.

This code is going into the Space Station (Declic), version control is a must for us.