There's a fourth and a fifth.

Post #21,455 by static 12/14/01 1:31:44 AM Reply	There's a fourth and a fifth. 4. Keeping state in your head. I often finding myself working on several pieces of code more or less at once, usually because one piece is called by several others. Keeping track of where you are up to in at least four or five disparate places is something that was nevered mentioned when I (many years ago now) did programming classes. But then, I can't think how on earth you would teach it! 5. Code modularity. This I learned through sheer experience. IMHO, it is the only way to learn it. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #21,477 by tjsinclair 12/14/01 10:07:48 AM Reply	Good ones! Tom Sinclair Speaker-to-Suits Rincewind could scream for mercy in nineteen languages, and just scream in another forty-four. -- (Terry Pratchett, Interesting Times)
Post #21,501 by wharris2 12/14/01 12:07:03 PM Reply	Code modularity 5. Code modularity. This I learned through sheer experience. IMHO, it is the only way to learn it. For the first two or three years out of college, I programmed haphazardly. I suffered the common affliction of many people who enters the work force: an attack of amnesia about stuff they may have tried to teach in college. I found myself writing routines with hundreds of lines of code, lots of global variables of course, routines doing several different unrelated things... A coworker happened to have Yourdon and Constantine's Structured Design on his bookshelf. Even then it was years old, and out of print, but I started reading it, and after having worked for a couple of years, all of a sudden a lot of the concepts they'd tried to pound into my head in college made sense. And like you, I think most people need experience before they can properly appreciate the concepts. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #21,573 by static 12/15/01 1:14:54 AM Reply	Oh, aye. I first realized what I was doing when I was learning how to write Win16 programs in C after quite a few years doing them for DOS. After three or four programs (projects), I setup a skeleton program to give me a head start every time I started a new one. Then I noticed repetitive code to do things like colour dialog box controls (e.g. for a splash screen), or handling DDE. After I created include files and libraries for that, I realized this was because I had taught myself modular programming. You need the bad experiences to know why it is A Good Thing. But you need to have then developed your own systems to know How To Do It. And then you need several different environments and/or languages so you get to Do It A Different Way. Only then are you ready to work with Someone Else's Idea Of Modularity. :-) Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #21,578 by wharris2 12/15/01 4:34:56 AM Reply	Oh sigh And then you need several different environments and/or languages so you get to Do It A Different Way. Sigh. It's difficult to crack the concrete one gets snared in it. I like Perl for this reason, in that it's hard to get set in the concrete, but the more I get into Perl the more I am horrified about it. Call it an old crusty C programmer blather, but Perl shorthands curl my remaining hair. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #21,505 by drewk 12/14/01 1:09:08 PM Reply	Well, if you do "5" right, "4" isn't so much of an issue If your pieces are small enough, you should never need to change more than one at a time. Whenever I find a problem that requires changing more than one class at a time to fix, I break something out into a new class, because obviously the functionality wasn't properly isolated. (Modulate this for "fix it now" vs. "fix it right" of course.) We have to fight the terrorists as if there were no rules and preserve our open society as if there were no terrorists. -- [link\|http://www.nytimes.com/2001/04/05/opinion/BIO-FRIEDMAN.html\|Thomas Friedman]
Post #21,572 by static 12/15/01 1:10:47 AM Reply	You mean it's less of an issue. I am currently employed doing PHP programming for a HTTP application. The code is actually fairly modular, but in only two weeks I have lost track of the times I've had to modify or extend some other module whilst working on two other (related) things at once and then had to repair some slight breakage because of my lower-level repair. Thank God for GNU screen and split windows in vim! :-) Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #21,583 by admin 12/15/01 9:36:28 AM Reply	How to make it even less of an issue. Write your unit/regression testing for everything as you go. When you make any change, run all the tests. Either a previous test will catch some breakage (most of the time), or you will find some new interesting border-condition breakage (write a new test to cover that too), or nothing will have broken at all. This kind of testing methodology makes even large-scale system changes very impact-free. Regards, -scott anderson

Welcome to IWETHEY!