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

CVS

[Anonymous Crowhead]

Use CVS or some other revisioning system.

Re:CVS

[g-to-the-o-to-the-g]

Mod parent up. CVS or SVN is the way to go all-round. Make sure its backed up, and set up viewvc and you'll have yourself a great place for keeping code. Not only is it easy to view from any machine, but you can quickly see a history of revisions.

Re:CVS

[jazir1979]

Choose SVN over CVS, there are many good reasons for it. Also, you'll get the view cvs part for free, since you can automatically browse the repository over http.

Reusable

[MyLongNickName]

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.

Inventing something once is Genius. Inventing something twice is stupidity.

Using OOP, code should be reusable without having to have some external database. I find that the more external processes one has, the less likely one is to use it.

Code should be self-documenting. I'm not saying you don't have external documnenation... just that well written code has good comments. A good practice is to comment function and classes before coding.

Break things down into components. Refactor. Then your code will be very reusable.

SVN

[anielsud]

I run a small web dev firm that does a lot in the way of PHP and JS, like yourself. What we have found works the best for our core library is a copy of Subversion running on our server. This way we all know exactly what the latest version is, and more importantly we can see how it became the latest version (i.e. what changes were made). A lot of tools run with SVN nicely. For instance, Trac talks to a backend copy of SVN and couples it loosely with a wiki and a couple of other things. A lot of hosting providers will also run a copy of SVN for you, like http://networkredux.com/ (We just switched over to them).

Of course, a root level folder on the ftp server can also work.

API's and Libraries

[sterno]

I think this is what people mean when they talk about libraries and/or APIs, but not really sure.

Not quite. What you are talking about sounds like just a repository of random code. A library is a specifically designed set of code to perform a given task or set of tasks. There's a certain amount of order implied in the term just as is implied by that big building where they put books.

API's are designed interfaces to a system to make coding easier to do. You don't have to understand how the underlying guts of the code works, you just program to work with interfaces. So you call the draw() method and a line appears on the screen but you don't need to know how to speak directly to the video card, etc.

AS for the original question, I have two suggestions. The first is to use CVS as a way to version your code. It's like have CTRL+Z for your entire project. It makes it much easier when you are adding new code because you can feel comfortable breaking it completely because you know you can revert it easily.

The second is to use a simple search engine to catalog your code. Google desktop would be up to the task. Just check out your code from CVS and put it in a directory somewhere. Then when you need code for some task you can search for it. If you're good about commenting your code, that should work like a charm.

Re:You need to learn the "include" statement

[menkhaura]

It may be all you *need* to get started, but I'm sure you know that PHP's OO these days is quite stellar. PHP 5 classes are now complete, with the whole OO shebang: polymorphism, encapsulation, interfaces, C++-like exception handling... the only thing that it doesn't support, and I'm not sure it *is* strictly necessary, is multiple inheritance. For the rest, you should try PHP 5, it is a very mature language and, IMHO, quite suitable for general purpose programming, not only web pages, even more so with the recent release of PHP-QT (there is already a PHP-GTK if that's your poison) for stand-alone GUI applications.

I don't. Not in the sense you're after...

[LoveMe2Times]

I've been programming for 20 years now, and I've worked in a variety of languages during that time on a lot of different things. And you know what? All of the code that I ever wrote before has pretty much zero value now, with a few exceptions. Especially at your phase of development as a coder, I think you'll find the value of code reuse after significant time has elapsed practically non-existant. Why? Well, because you'll find that your abilities grow substantially every couple years, and you're almost always better off to start with a clean slate rather than fooling around with your old code.

Now, there's a few caveats here. Another thing that happens over time is you learn to stop re-inventing the wheel and to use pre-existing libraries. Right now, you're just unaware of their existence, but you'll learn where to look if you make a little effort. In fact, you'll find that existing libraries tends to heavily influence choice of language to use. So it turns out that most things that are really worth reusing are already available, and you should use those solutions rather than maintaining your own. Sure, write your own for fun or education, but when you get a serious project, you've got no use for it. In some cases, you'll find that there's no library available, so you write something from scratch, but 3 years later, you find that somebody else has made a nice library that's much better than what you hacked together. Several times I have ported code from my own hacked together solution to a more mature library. It's a natural progression, and there are a thousand times more libraries freely available today versus 10 years ago.

Now, having said all that, there are still times where you want to make something that is generically reusable. The point is, though, you should really make an effort to make a library out of your code. I have done just this on a handful of occasions. Then, put it up on SourceForge or something similar dedicated to your language of choice. I have a few libraries up on SourceForge, some only a few hundred lines of code, but some other people have found them useful because I made the effort. Other people have suggested CVS or whatnot, and SourceForge will give you that.

Maybe the real gist of your question, though, was about making your code into a library? While the technical details of making a lib, dll, so, jar, pm, etc vary from language to language (sometimes compiler to compiler), here's a few pointers:

1. This is just good practice in general, but you have to make the code *independant*. It has to stand on it's own. You might have heard about encapsulation, this is what they're on about. Make sure your application code no longer has to make any assumptions about how the library works. Get rid of "magic numbers" and define well-named constants. Make some effort to make the libraries data protected so app code can't screw it up.
2. Make all of your functions meaningfully named. Make sure each function sanity checks it's inputs. Return meaningful errors anytime something goes wrong. This can be the hardest part. You have to check for and return errors *rigourously*.
3. Define error constants, and provide a function to get a meaningful error message as a string. Alternatively, if you're using exceptions, make sure the exceptions can provide a message as a string.
4. Provide appropriate initialization and cleanup/shutdown routines. Clearly define whether or not the library or the application "owns" any resources (memory, file handles, database connections, sockets, and so forth) so people know whether or not to release them.
5. Make an effort to decompose your functions to expose a fine-grained interface, and then write "convenience" functions that use the low level functions to implement common needs. For example, if you have something that opens a file and processes it, break that down into something that works on a memory buffer and provide a convenience function that opens a file and feeds it into the memory buf