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
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.
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..."
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).