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?"
He's new and self-taught. Cut him some slack. I started becoming self-taught on a TRS-80 Model I. The code I wrote was a joke. I picked up lingo along the way. After getting away from computers, I re-entered the computer programming field, only to be faced with a new paradigm -- OOP, n-tier apps, etc. It took a lof of reading, wading through different opinions on design, idiots who have written a lot on the subject and don't know what they are talking about, etc. It was a lot to absorb, but after a few years of trial by fire, think I am on top of these things.
He is at the beginning of the curve. Laughing at him won't help.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Copy and paste? Read his question again. He is not an advanced programmer. Don't get him tied up with unnecessary technical details.
When he is a program manager for a team of 20, then he will need something more robust.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
It also depends how much you're working in a field where optimization matters. If you need routines that run very fast you'll have to implement custom routines specific to each project. On the other hand, if you're putting up a bunch of web pages where you just want enough stuff on the pages to keep the pages from looking too plain then reusing code is a good idea.
>What I don't think is ok is being ignorant and asking others for advice without doing any basic research yourself.
I'm all for bashing Ask Slashdot questions that should be Googled and "Do my homework plz" type questions but he really just a kid (look at his homepage).
Kids are suppose to be ignorant and ask advice about really basic stuff.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
I often find that adding comments in the PHP/MySQL/Whatever manual under the function you are using is helpful. That way next time you are looking up how to do something (maybe a year later) your snippet is waiting for you. Also writing articles about how to do something and getting it posted on community code sites is good. Otherwise I'm a fan of plain text files or just keeping copies of the projects you work on and poking through them later. I find that I incrementally improve on my foundation code over time. I don't believe that re-writing code is a bad thing.
Me lost me cookie at the disco.
You're supposed to write new code from scratch for every PHP project you do. You obviously must not have browsed freshmeat lately.
I'd say asking the slashdot readership IS doing research. If you've got time to flame him for asking a question clearly you weren't too busy to respond to his question.
The smartest way to get knowledge is to ask the people that know. And by posting on Slashdot it's not like he's barging down your door or sauntering into your cubicle and demanding your attention. It's a very passive non-intrusive inquiry. You read the post, you responded, you have no reason left to complain about this.
Plus, as a largely self-taught programmer myself I know that asking a question from someone who knows can sometimes get an answer 10 times faster (and 10 times more clearly) than reading a bunch of manuals frequently written either for dummies or for experts. That in-between period when you don't need someone explaining how an if-statement works but you don't really quite know the next step is a difficult phase. In my opinion this isn't a question of laziness - it's a question of efficiency. There seem to be plenty of people here who want to help him. Why don't you kindly get out of their way?
-stormin
The Southern Baptist Convention has creationism. On Slashdot, we have porn.
I can't believe his age is even being discussed. He could be 33 for all I care. since when is it a crime to ask a question? Again - he's not wasting anybody's time. Anyone who resonds to this thread to complain about him proves they have the time to deal with the issue at least a little bit.
I think it's crazy that some poor guy manages to get his question posted on slashdot - which means he's probably going to get a wealth of information - and he ends up having the legitimacy of his question debated in terms of his age!
It's people like this that give techies such a bad reputation. It's one thing to laugh in fun at the dumb users who try to use the CD-drives as cup holders. It's another thing to get irritated with users who expect us to fix their messes after the screw stuff up. But to smack down someone who's actually trying to learn to do it on their own because you don't like their question? That's just elitist and anti-social.
-stormin
The Southern Baptist Convention has creationism. On Slashdot, we have porn.
Real men don't make backups... the put their code on a public FTP site and let the world make copies - linus
-- Given enough time and money, Microsoft will eventualy invent UNIX.
What? What does any of this have to do with the question? He didn't ask for the features of OOP; he asked how to store/organize his libraries/modules/classes/headers files/what-have-you. The implication that simply using an OO language - regardles of the exact language or platform - obviates the need for basic file storage and management is ludicrous.
On top of all that, source repositories (I assume that's what you mean by "external databases") aren't primarily intended to help folks oranginze and store things; they're for revision control, so why you bother to bash them is beyond me.
All I can say is, "Wow". Code reuse has been around for 40 years.
FORTRAN card-wallopers would keep routines as stacks of cards in their desk drawers. The C rtl is reusable code, as are libm, Turbo Pascal units (am I dating myself?), SQL stored procedures, GTK, the 10 jillion Perl modules, etc, etc.
I don't know much (anything, really) about how PHP and JavaScript store software, but if this were a 3GL, you could group your common code into funtional units that compile into
"I don't know, therefore Aliens" Wafflebox1
Printed out, of course. File cabinets full.
Don't laugh!
I got my first computer (Texas Instruments TI-99/4A) in the early 1980s, back in the days when Compute! and other similar magazines were *full* of games and other programs which you'd have to type into your computer.
I credit them with my blazing fast typing speed, my good accuracy typing code (which is a lot different from typing text, of course!) and my ability to troubleshoot.
I'd type run, and I'd get
* INCORRECT STATEMENT 440
Then fix that line, and the program would run... but some text would be wrong somewhere.
890 CALL SAY(SEG$(1,B,$OUTWORD)) :: CALL SOUND(10,2500,0)
(Oops, the text segment was supposed to be from 1 to A, not 1 to B.)
Now, it's honestly been 15 years since I last did *any* programming in TI Extended BASIC, but I still remember most of the syntax, including CALL SOUND being (duration, frequency, volume {,frequency2,volume2,frequency3,volume3,noise}).
The repetition from retyping is valuable rote.
The other thing is how well can we trust media? Tape has finite lifespan, disks have finite lifespans, and how do we know the security of data trusted to CD and DVD dyes? They haven't been around long enough to say for sure. So you're gonna have to make a point of recopying your media every year or so in order to ensure any deterioration doesn't cause loss of data. Fine, now you'll have multiple backups, in a few years at least one of those DVDs should be legible.
On the other hand, print the code to the laser printer (or even the old Okidata dot matrix every true computer geek still has kicking around - hell, I still have my trusty first printer, the Xerox Diablo D25 daisywheel; I still sometimes use it to print letters and stuff just for the fun of it).
Once it's on good quality paper, you know you'll be able to OCR it someday. Whether it's tomorrow or 50 years from now, I think we can rest assured there'll still be paper - and therefore scanners.
Oh, and by the way, importing my old TI and Amiga software into my current machine was no fun. I had cassette tapes, 5.25" diskettes in TI format, 3.5" diskettes in Amiga format, and that whole Amiga hard drive image. Transferred to my PC by XMODEM and a Laplink cable. All these tasks were possible only because I still have my old hardware, and it still works - and PCs still, for the most part, have RS-232 ports.
Fire and Meat. Yummy.
Version control is good advice, but I think he/she means "how do I maintain a code library" not just how to physically store it or revisions. In other words, how do you maintain pieces of code in a way that allows you to easily incorporate them into new projects.
For me the answer is to create individual projects or modules (using version control) that contain a logically connected set of components. Version control is really just a means to the end of actually making the library available in a convenient way.
"he drew his sword Ringil that glittered like ice... and he wounded Morgoth with seven wounds..."
This seems reasonable when one don't actually write real world code, instead just playing around with "what I want to do". Often, reinventing the wheel is cheaper than trying to use an old wheel, and trying to make something that can be perfectly reused is more expensive than writing it several times.
Writing things several times also leads to you knowing what things you did right and wrong, so the second or third time you do something similar can be much better. It's important to be careful on go #2, though - it's easy to try to solve all the things that were bad with the first system, and overengineering. That's known as "The Second Systems Effect".
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I store my old code between my ears, in the wetware. When you've been programming as long as I have, you don't write code anymore -- you just remember it and type it in again...
"World Domination - a fun, family activity"
There MAY be a good reason to use CVS in that CVS is slightly more trivial to set up; this Subversion tutoral makes the SVN setup fairly painless, too, though.
Subversion is likely to give you less pain in the long run than CVS, though.
<soapbox>
I think SVN's lack of distribution support might end up being the worst thing to happen to open source ever. Distributed development can boost the open source model A LOT, and CVS suckiness made it much more likely that this would become the norm. Instead, Subversion creates a much higher bar that has to be jumped, delaying the full use of distributed systems a lot, possibly effectively killing it. Unfortunately, people need to think long and carefully about version control, development, hurdles, personal effort economics, and open source culture before the impact of this is obvious.
</soapbox>
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
Very true, but if all of your code uses the same library you have to be very smart up front when building it to avoid not having to rebuild existing projects every time you update the codebase.
For the first application, I create function foo(). Later I find I need to do something very similar to foo() for a new application that I didn't anticipate the first time around. Should I have assessed every possible use of foo() when creating it originally (most of which I will never use)? Or should I change foo() and update every application that uses it? Or should I update foo() and be hampered by my original interface to it? Or should I take my original library, modify foo() and have each application use the version specific to it? If I need to make changes to the original appication later, I can make it use the newest library to take advantage to the updated foo(), but unless there is a compelling reason to it's stupid to change working code.
Of course, with experience, you can make foo() very robust on the first attempt, but read the OP, he's just getting warmed up and even experienced programmers can find new uses for old functions. Eventually, you get your libraries to the point where the interfaces are pretty consistent, but not off the bat and not for a novice programmer.
Side comment to the OP: Be aware of the balance between too much abstraction (don't have one function or even library that does absolutely everything) and too much specificity (see PHP -- different functions doing extremely similar things).
But this isn't a situation in which copy-paste would help either. It only helps if you need to use the same code in every application, not similar. In fact, copy-pasting foo() everywhere is a guaranteed way of losing track of which application uses which version and what exact semantics apply to them. It will quickly turn into a nightmare.
The correct way to handle this is to make function foo_two(), and link that to applications that need its semantics. If the function is complex, you could put the common parts to include files - that way both foo() and foo_two() can use them without needing to copy-paste them.
After all, if function foo() does something, and you need a function which does something else, why on Earth would you call it too foo() ? It is easy enough to make stupid mistakes when programming without purposefully trying to confuse yourself or other maintainers. KISS - Keep It Simple Stupid ;).
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
All in all good advice; I have some additional tips for PHP.
I think the number one issue for code re-use is avoiding name collisions. PHP doesn't support namespaces, so my approach has evolved to building classes, even for very procedural functionality. I have one library named after my (very unique) username that contains all the functionality that I find useful for my own projects. I usually repackage any functions I use from there in the case of outside projects that other people will be working on.
I also have to talk a little bit about PEAR. There are some really fantastic libraries there, but considering that it's supposed to be a peer-reviewed repository, it has a lot of crap too. Mostly in the form of stuff that's never made it out of beta, but also there are some libraries with untested functionality. Often this comes in the form of poorly conceived generalization of a problem. One of the things that makes an excellent programmer is the ability to decide how general a solution is ideal for a given situation. Always take third-party code with a grain of salt.
Finally, if you are serious about programming, take some time to learn the advanced features of other languages. PHP is an extremely utilitarian language, lots of built-in functionality, lots of free code available, but its a bit like a stone hammer--very crude. I would say almost every other language has more to offer in terms of expanding your programming mind: C, C++, Java, Perl, Ruby, Python, OCaml, etc. Understanding these languages will help you write better PHP. Also, don't be fooled by Javascript's seeming simplicity, it's actually a very powerful dynamic language with unique features worth studying.
CVS integration works really well in Eclipse, SVN integration is promising, but can be unpleasant. This alone keeps me using CVS.
-fb Everything not expressly forbidden is now mandatory.