Re: How to be a good programmer?
From: Strangely Placed (binary_at_eton.powernet.co.uk)
Date: 12/23/03
- Next message: Randy Howard: "Re: Letter to US Sen. Byron Dorgan re unpaid overtime"
- Previous message: db_happy: "Re: changeable structures"
- In reply to: Try Kret: "How to be a good programmer?"
- Next in thread: osmium: "Re: How to be a good programmer?"
- Reply: osmium: "Re: How to be a good programmer?"
- Reply: osmium: "Re: How to be a good programmer?"
- Reply: gswork: "Re: How to be a good programmer?"
- Reply: CBFalconer: "Re: How to be a good programmer?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 23 Dec 2003 10:41:53 -0800
[I apologise for this long reply. I lack the time to make it shorter.
I also apologise for posting the darn thing through Google.]
Try Kret wrote:
> Hello ,
>
> Are there any recommends on how to be a good
> programmer? especially, a good anylisis and conception.
For a programmer, programming is immense *fun*. It's hugely enjoyable!
That's the first thing. If, after a few weeks, you're not enjoying it,
don't bother doing it. Find something else to do, and I wish you all
the best in whatever it is you decide to do. If you don't enjoy
programming, you are unlikely to be any good at it.
If you /do/ find it fun, then that's brilliant. (Don't, under any
circumstance whatsoever, allow any employer to discover that you enjoy
programming so much that you'd do it for free if you had to.)
So - how to be a *good* programmer...? Well, that's tricky.
Programming requires a certain mindset (or, rather, one of several
mindsets, all contradictory!); I'm not sure how best to communicate
that mindset to you, and it may in fact be impossible to do this. But
I guess the *most* important thing to get your head around is the idea
of *correctness*.
If your program doesn't do what you want, obviously it's not correct.
But it is also possible for your program to appear to do what you want
even when it's not correct. And therefore, it might break later under
circumstances that you did not foresee at the time you wrote the
program. That's a hard lesson to learn, and the best programmers are
those who learn it early. (Needless to say, I learned it quite late!)
Once you get into the habit of writing robust, correct code, you're
well on the way to becoming a first-rate programmer.
Don't worry about speed. It's much, much easier to make a correct
program fast than to make a fast program correct. In any event, a
correct implementation of the correct algorithms is likely to be fast
enough to satisfy the most avaricious of racing drivers. Computers are
pretty darned quick nowadays, and it takes a fair amount of naivete or
stupidity to slow them to a crawl. Choose the right algorithms,
implement them intelligently, and the speed will normally take care of
itself.
Rather, focus on readability and simplicity. If you can't read a
program, you can't fix it. If you can't understand a program, you
can't fix it. Brian Kernighan once observed that debugging is twice as
difficult as programming. Therefore, if you write code at the limit of
your cleverness, you aren't clever enough to debug it! So make your
code as simple as possible (but no simpler). And it's probably best to
avoid ludicrous naming conventions that make it six times harder than
it should be to read your code out loud.
Whichever language you learn first (and I mean "first", for you will
learn several if not many languages), learn it *well*. Find a
newsgroup devoted to that language, and ask them which are the best
books available for that language. On the whole, Web tutorials are
pretty dire, so get a really good book instead, one that is worth the
money. (Aim for quality, not page count.)
What should your first language be? If you have chosen one already,
well, that'll probably have to do, since I doubt you'd change horses
in mid-stream just on my say-so. But if you haven't, I would suggest
Pascal, since it was *designed* as a teaching language. Having learned
to program, though, that's the time to start messing around with other
languages. (With the admirable exception of Delphi, hardly any Pascal
implementations are actually used in the so-called "real world". It's
a great teaching language, but relatively few use it for actual
programming.)
Don't fall in love with any one language. I fell in love with BASIC,
and then felt very guilty about falling in love with C. Now I feel
guilty about playing around with C++ when C is out shopping. And
occasionally, I sneak back to BASIC when I think nobody's looking.
Programming languages should be tools, not lovers!
But it's only natural that you will find some language or other to be
your favourite. For me, it's C, although I do have a sneaky regard for
C++. For Programmer Dude (elsegroup), I think it'th probably Lithp
nowadayth. For John Krahn, it's clearly Perl. Chuck Falconer is a
Pascal fan, I believe. So there's no one language that *ought* to be
your favourite!
Whichever language becomes your favourite, learn that language inside
out, upside down, and back to front (and, if possible, the right way
up, too). If the language is defined by a Standard (ANSI, ECMA, ISO,
whatever), get a copy and read it. Read it thoroughly. Read it so that
people get sick of hearing you quote from it. Then read it some more.
If it's a language that is implemented by more than one supplier, get
several implementations (several popular languages have free
implementations available for them), so that you learn the difference
between what works *HERE*, what works *THERE*, and what works
everywhere. (E.g. for C++, you might get hold of Borland C++, which is
free, g++, which is free, and Visual C++, which isn't. All are quite
different in what extra features they provide, but on the other hand
all of them (more or less) support the core C++ language.) If you have
two or more different platforms (MS-DOS, Windows, Linux, FreeBSD,
MacOS, whatever) available to you, so much the better. Use them all.
Learn at least one assembly language, and preferably more than one. By
learning more than one, you will soon learn that there's more than one
way to do stuff. This will also teach you valuable lessons about the
machine itself - lessons about memory, and registers, and pointers,
that are much harder to learn any other way.
So much for languages. What about programming itself?
Learn the basic algorithms and data structures. Learn why they're
useful, and learn how and when to use them. Learn about arrays,
vectors, lists (linked, double-linked, circular, whatever), queues,
dequeues, stacks, trees of all kinds, hash tables, graphs, the lot.
Learn how to store data efficiently, in a way that's easy and quick to
retrieve. Learn about sorting algorithms (not because you can't pick
one up off the shelf easily (you can, after all), but because they're
a great way to pick up important lessons on algorithm design). Learn
about searching algorithms too. For example, the Boyer-Moore search is
a great object lesson in turning a clever idea into an efficient
algorithm. Learn about hashing, tree-balancing, image transformations,
compression, permutations, etc. This is a non-exhaustive list. (Don't
feel you have to do it all at once. Take things one step at a time.)
When you're doing programming exercises, it's always worth doing them
twice. Once in the normal way, and then again about a month later.
DON'T look at your old solution when designing your new one. Once
you've finished the second attempt, compare it with your first. If
you've anything at all about you, you'll see a dramatic improvement in
the second solution, compared to the first. This can be very
encouraging!
Whether you choose to concentrate on graphics, network programming,
sound, animation, cryptography, text processing, numerical analysis,
program translation, natural language, database stuff, or whatever, is
entirely a matter of whether you're interested in those topics. Nobody
can be an expert on everything, after all. But, whatever you choose to
focus on, make sure you know the basics, and make sure you get
excellent books on that particular sub-topic.
+------ I M P O R T A N T N O T E ----------+
| |
| Don't forget to *read* the excellent books. |
| |
+---------------------------------------------+
As a general rule of thumb, the thicker the book, the less money it's
worth. (This is obviously not 100% true!, but it's depressingly
common.) Having said that, there are some extremely good books that
are also pretty thick (Knuth and Stevens being the obvious examples).
Here is a list of books which I wish I'd known about when I was just
starting out. They are in alphabetical order of (principal, where
applicable) author's surname, so don't read anything into the order.
This is kind of my "Top 40"(ish), the books I really wouldn't want to
be without; plenty of good books on my shelf didn't make the cut.
The ones marked [DI] are the ones I'd take with me if I were stranded
on a Desert Island - the real classics.
"Graphics Programming Black Book", by Michael Abrash.
[DI]"Compilers: Principles, Techniques and Tools", by Aho, Sethi and
Ullman.
"Programs and Data Structures in C", by Leendert Ammeraal.
"Modern Compiler Implementation in C", by Andrew Appel.
"DOS Programmer's Reference", by Terry Dettmann, Jim Kyle, and Marcus
Johnson.
"Assembly Language, Step-by-Step", by Jeff Duntemann.
"Computer Graphics: Principles and Practice", 2nd edition (in C), by
James Foley, Andries van Dam, Steven Feiner and John Hughes.
"C - A Reference Manual", 4th edition, by Samuel Harbison and Guy
Steele.
(Er, modesty prevents me naming the next one. Moving right along...)
[DI]"Godel, Escher, Bach: an Eternal Golden Braid", by Douglas
Hofstadter.
"Computer Algorithms", by Ellis Horowitz, Sartaj Sahni, and
Sanguthevar Rajasekaran.
"C++ Components and Algorithms", by Scott Robert Ladd.
"C++ Templates and Tools", by Scott Robert Ladd.
"The Practice of Programming", by Brian Kernighan and Rob Pike.
[DI]"The Unix Programming Environment", by Brian Kernighan and Rob
Pike.
[DI]"The C Programming Language", 2nd edition, by Brian Kernighan and
Dennis Ritchie.
[DI]"The Art of Computer Programming", Volumes 1, 2, and 3, by Donald
Knuth.
"Programming with Pascal", by John Konvalina and Stanley Wileman.
"Gtk+ Programming in C", by Syd Logan.
[DI]"Principles of Programming Languages", 3rd edition, by Bruce
Maclennan.
"Professional Linux Programming", by Neil Matthew and Richard Stones.
[DI]"Code Complete", by Steve McConnell.
"Programming Windows", 5th edition, by Charles Petzold.
"Windows Sockets Network Programming", by Bob Quinn and Dave Shute.
"Advanced Windows", by Jeffrey Richter.
"3D Graphics Programming", by Sergei Savchenko.
"Applied Cryptography", 2nd edition, by Bruce Schneier.
"Software Solutions in C", edited by Dale Schumacher.
[DI]"Advanced Programming in the Unix Environment", by W Richard
Stevens.
[DI]"TCP/IP Illustrated", Volumes 1, 2 and 3, by W Richard Stevens.
[DI]"Unix Network Programming", Volumes 1 and 2, by W Richard Stevens.
[DI]"The C++ Programming Language", Special Edition, by Bjarne
Stroustrup.
"C Programming FAQs", by Steve Summit.
"Compilers and Compiler Generators", by Pat Terry.
"Linux Programming by Example", by Kurt Wall.
"Programming Perl", by Larry Wall, Tom Christiansen and Randal W
Schartz.
"Data Structures & Algorithm Analysis in C++", by Mark Allen Weiss.
[DI]"Algorithms + Data Structures = Programs", by Niklaus Wirth.
I was going to add a list of the software tools I use most when
programming, but it occurred to me that this wouldn't be of much use
to you, since every programmer is very different from every other
programmer in this respect.
A last word or six:
Keep a logbook. Record in it not only what you did right, but also
what you did wrong. When you hit a bug, write down (a) what program
you're writing, (b) what should happen, (c) what's actually happening,
(d) what steps you take to isolate the bug, (e) what you did to fix
the bug, (f) what steps you take to ensure that that bug can't happen
again, (g) what you think you should do when it does(!), and (h) what
you *learned* from the debugging experience.
Also use your logbook for writing down ideas for new routines, for
improvements to old routines, for new data structures or classes, for
new programs, and so on. Who knows? You might just wake up one night
with the next world-killing application fresh in your mind. Make sure
you write it down, or you'll simply forget it.
Start building a library of useful routines NOW. If you change
language, and your new language doesn't let you re-use your old
routines, let your first task be to port the routines you can't live
without.
Once every few months, look over your library code. Does the code now
look rather naive? If so, well, write a better (faster, more robust,
more portable, more general, whatever) version, and test it against
the old routine.
Now all I need is a time machine. If I'd had this advice in 1982, I
might have been world-famous by now. (Sigh.)
-- Richard Heathfield : binary@eton.powernet.co.uk "Usenet is a strange place." - Dennis Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
- Next message: Randy Howard: "Re: Letter to US Sen. Byron Dorgan re unpaid overtime"
- Previous message: db_happy: "Re: changeable structures"
- In reply to: Try Kret: "How to be a good programmer?"
- Next in thread: osmium: "Re: How to be a good programmer?"
- Reply: osmium: "Re: How to be a good programmer?"
- Reply: osmium: "Re: How to be a good programmer?"
- Reply: gswork: "Re: How to be a good programmer?"
- Reply: CBFalconer: "Re: How to be a good programmer?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
