Slashdot Mirror
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?"
Use CVS or some other revisioning system.
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.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
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.
In the real world, though, I just copy code from previous projects into the new one as needed. I'm usually careful about keeping things modularized so this hasn't been a problem so far, but I tend to forget what I was doing on my old projects and have to spend time figuring that out.
I'm not sure if there's software for this or not. Did you try searching for 'code' on freshmeat? :)
Get a subversion over http (apache) server going and turn on web-dav auto-commit.
)
This way you can have full version control with a client like Tortoise SVN and read access to any file with any web browser.
The web-Dav auto versioning will allow you to write to any of your files with any web-dav client including windows explorer, internet explorer, ms visual studio, macromedia home site, cold fusion studio, many other development environments, microsoft office and lots more.
Subversion info: http://en.wikipedia.org/wiki/Subversion_(software
WebDAV info: http://en.wikipedia.org/wiki/WebDAV
Subversion: http://subversion.tigris.org/
Tortoise SVN: http://tortoisesvn.tigris.org/
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.
This sig has been temporarily disconnected or is no longer in service
Once in Sourceforge, you get CVS and all the goodies. Better than using GMail for it.
If it's not sensitive, and I wouldn't mind people using it, I like to store it on my tagged code snippets site. It helps me find useful bits and pieces again at a later date as I can always remember a word or two which I tagged it with. 1000 other users seem to enjoy it too :) and if you're looking for inspiration you can subscribe via RSS.
Since this is 2006, there is no point in starting with CVS.
Use SVN if you will be the only person committing stuff in to the repository. If you plan to share the code in an Open Source project with many people, and each will have their own distributed repository, then look into something like bzr from Canonical.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
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.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
Storing your code is just the beginning.
But to start, use SVN. There's not a good reason to use something else, and having the history of your changes will (in some ways) be far more important than having the code itself. If SVN is a bear to put up with, and it's just you, you might consider RCS, but RCS will eventually make you jump through so many hoops that sooner or later you'll be looking at SVN.
After that, you'll need to recode your code to become more useful over time. At first, the solution fits the problem, and the problem fits the website, and that fits the specific task you were trying to perform. After some time, your needs will change. The second time you want to use your code, you'll notice that it doesn't really fit. This is where your challenge starts.
Challenge yourself to NOT write the 2nd and 3rd products that use your code to make compromises for the "way this library needs to be used". Rework parts of the library to make it more useful in more situations, and rework both the old and the new projects to use the new library.
Then try to make a third application that uses the library in a slightly different way. Once again, don't write the application to fit the library, but modify the library to fit the way the application uses it. At the same time, check that the old applications both keep working on the rewritten libarary's code, and keep them up to date with the changes in the library.
After a few trips on this merry-go-round, you'll begin to notice a few things about code maintenance, code reusability, and code maturity. Sure, you could just read about it in a book, but that would rob you of an education. You MUST see it happen in person to understand it. If you're doing things "correctly" you'll notice a few things:
1. Each time you write a new applicaiton, the library needs to change less and less, but it's still easy to use.
2. Good libraries don't force different applications to be written the same way. Bad libraries require the application to be written in ways that make using the library uncomfortable.
3. It's impossible to make code reusable without some understanding of the various ways you might be likely to use it.
The real test is when you find yourself writing documentation for your library so you can hand it off to someone else to use without the need for them to see your source. Sure, you could give them a copy of the source code too, but if they have to read it, you've only made it reusable for you, and that's a small audience to learn from.
Good luck, and don't worry if you fall short. Writing good, flexible, reusable libraries is often much harder than writing the applications that use them. Just remember, it's not a library if only one application uses it. It's not flexible if only one style of application uses it. It's not good if you have to read it's source code or documentation that looks like it could be source code.
Sincerely,
ELB
The JSAN project (openjsan.org) project has already defined a really neat way to build your JavaScript code as reusable modules, with unit tests and everything!
I highly recommend you follow their JavaScript package style, even if you don't use the JSAN modules themselves.
From my experience: :)
- If you have unit tests, keep them with a copy of the program that runs them.
- If you dont have unit tests keep a running little example of how to use it - and start looking into using test-driven development for these pieces of code you'd like to rely on.
- have a 'code blog' in a plain txt file where you track some of your main decisions and ideas to-do. As time goes by, I have tended to idealize my past code into doing things I had only wished it did
- If the code uses databases, external files, etc. keep those too
- If there are interesting things that need to be done during build, make sure you keep those too
- Choose some SCC mechanism, svn or whatever suits you, plenty of posts...and archive a plain copy of the
- if you plan on archiving for maaany years and writing in some propietary lamguage, keep a version of the editors & compilers safe with your code. I had to rehash a lot of prolog once.
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:
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.
... on every file you accidentally added. The only way to know which ones, is by committing and waiting for the error.
If you use fsfs, you can just delete the last revision. 1 revision=1 file in that one. Otherwise, I'd say that you've hit upon the point of having a revision control system. From a technical standpoint, not having 1 to 1 mapping of files in the repository to files in the system allows you to make cheap copies, do directory versioning, do branching easier, and make backups easier.
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
FUD. You was probably some other error in there too. I've done exactly this and it worked. Or it could be that whole "not using Berkley DB" thing.
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.
In the subdirectory: svn switch --relocate [new server]
The subdirectory will update to the new place; rest of it will update to the old place. Don't blame subversion that you can't be bothered to learn how to use basic commands in it.
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.
I guess its just me. The solution seems obvious: don't use Berkeley DB as the backend. I don't. I wouldn't even touch a database format that only works right on ext2 partitions. That's already far too picky for me. What if my ext2 partition dies and I don't have another handy?
And the fact that you can do incremental backups and actually get only new data is a nice plus.
Mod me down and I will become more powerful than you can possibly imagine!
Make sure you are using #include (or #include_once) and function calls
r
Put as much "code" into function calls in files grouped by purpose, database, formatting, drop-down-menus, etc... Keep the function calls in their own files that are included when you need them.
You want to strive for 2 layers of code, one is the page being presented, which can change every time. While the rest of the code is "included", those included files get easier to re-use over time & you figure out how you like em.
My favorite model for breaking down code into modules/libraries is the Model-View-Controller (MVC) http://en.wikipedia.org/wiki/Model_view_controlle
As you start to tweak/modify your librarys/modules storing them in CVS is great way to track how they evolve over the ages