Programming Techniques (that you won't find in textbooks) By the Silver Ghost CAUSE FOR CELEBRATION: Thieve's World FIDO is back up! (cavort cavort cavort) 616/344\2718 @ 3:1200, 24 hours, a haven for hackers and many other minorities Perusing many modern-day textbooks, you'll find advice for the programmer along the lines of "always follow the One-Entrance, One-Exit rule for subroutines," and "write clear, commented code." As a graduate of a few classes that have used these textbooks, I'd like to point out several pieces of information, show some handy tidbits, and debunk some myths. Information ----------- * Nine out of ten graduates of "structured programming" classes go back to writing any old way after they're out of the class. * Eight out of ten professors do, too. * Every programmer has a point of complexity. Beyond this point, the pro- grammer will be unable to efficiently debug an unstructured program. - Structured programs have this point, too. But it's a lot higher. - For some people, this point is incredibly high in the first place. - Ergo: for some people, and for most purposes, structure is unnecessary. - Few people can take a six-month vacation and expect to find the point unchanged. * If you're sceptical, try writing only structured programs for a month, and then try writing only unstructured programs for a month. (Make sure no programs overlap.) Compare months as to (A) enjoyment, and (B) efficiency. * Programmers have emotions too. If you get pissed at the computer and find yourself punching inanimate objects (or worse, animate objects), take a break. * Some techniques are like knowing Geometry--they may seem worthless, but they're nice to know, and you never know when you may need them. * For relatively unimportant applications (mailing label programs etc.), the capabilities of the machine may actually matter less than your appreciation of it. If an Amiga's graphics aren't really necessary, and if you feel more comfortable on an Apple, by all means write it on the Apple. * Grammar and spelling mistakes don't impress prospective employers. * If you have eliminated the impossible, what remains, however improbable, must be true. But usually you've overlooked something. * Gremlins exist. Tidbits ------- * Keep a pack of dental floss near the computer. * If you chew your fingernails, coat them in vinegar and let dry. * True Hacking Enjoyment comes from deftly solving a tight problem. However, you will frequently be in search of a paycheck, in which case T.H.E. can be ignored. Therefore: - Fix bugs on hunches...you're good enough to guess at what's going wrong, so guess. Play hunches until you're stuck, then get methodical. - It may be faster to start over. - When looking for specific combinations: it is a helluvalot faster (in programming time) to generate random combinations and throw the bad out than to write code that only generates the right combinations. - If the program doesn't run in real time, don't bother optimizing code for speed if it isn't repeated more than 10,000 times. - If you're the only one reading your code, fuck beauty. * Don't keep a record-book of techniques you want to learn. If they're important enough, you'll learn them on your own. If they're hard, use them until they're almost commonplace. * Always make room for an hour's worth of equipment failure at the most inopportune time. * Hacking is personal and spur-of-the-moment. You can't do any serious hacking in an hour when you're at a friend's house. * Find background music that requires little thought, Muzak or country or something. * Wear comfy clothes--no shoes, short sleeves. Make sure you're warm. * Make backups frequently. Switch between using the backup and the original. * Find someone who knows more than you. Call that person when you're stuck. Myths ----- * Whoever writes a book obviously knows more than you do. * All PASCAL programmers are the same; thus, they should all use the same PASCAL textbook. * You should memorize the basics of a language before you get to the fun parts. * Certain languages you should never use (BASIC, f'r instance). * It doesn't matter what you're writing, you should get in the habit of writing structured programs. * You don't need to learn how to structure programs; good hackers can always get along without structure. * You can be a specialist without having a general education. -:-