1–10 of 13 posts
--
[1] pg is right about cofounders. At least for some people, including me.
Another thing to do is to go to code samples online at the example sites. Type them in and/or download them and play with them.
Yet another thing to try is to do a port of a program to another platform. Even if you are not successful, you should learn a lot.
The key is to take more than one approach, as there is no one right way, there is not one true path. Immerse yourself in different programming activities. The important part is practice, practice, practice, like the story on going to Carnegie Hall.
Me? One of my earliest bigger projects was porting an old star trek game written in Altair basic to Apple Basic. I had only mimeographed printouts published in a book of computer games back in the 1970's. Arrays were not handled the same between the two versions of basic, so I had to come up with a different array scheme than was in the book.
if there are already tests, try reading those.
Learning to just read the code requires writing alot in that particular language (I find writing teaches you alot more than reading). When some piece of code uses some aspect of a language in a way you don't understand, go figure out what they are doing, internalize that concept, and go write some code yourself that uses that same concept in that language.
In my experience, writing alot of code is the best way to learn to read it. You'll discover and truly understand why certain things are done certain ways once you've had to go through the pain of doing it any other way. One of the 'first' examples you might run into is how every single header file in a c/c++ library seems to start with an #ifdef/#define combo, and end with an #endif. It might seem a bit bewildering at first. But when you run into your first case of multiple includes of the same file, you'll quickly see why they do it.
As for actually 'understanding' a big pile of code, that's more difficult. This is where you understand the language just fine but you need to try to wrap your mind a giant pile of someone else's code. You have to immerse yourself in their codebase, figure out where all the important files are, and so on. Take it small chunks. Pick a feature, trace the code, put in print statements, etc. And you -really- need a way of quickly navigating the code (jumping to decelerations, switching between header/source, etc). Many IDEs provide some level of functionality to do this. Personally, I use emacs and etags.
Some people really loathe these tools, but I think they're invaluable when someone drops a pile of spaghetti code in your lap and tells you to support it. Figure out the entry point to the code, set a breakpoint in main() or something like that, and start stepping. After ploughing through a few of the code's basic transactions, you should have a sense for the data structures and abstractions it relies on, if any. Then, you should be able to read individual functions and such to get the gritty details. The use of threads substantially complicates the picture, of course.
Some of this is just proficiency in the specific language, but it's more about the concepts and idioms of programming in general. I've fixed a bug in an open source python project, and I couldn't write a "Hello World" program in python without a reference.
But do note that "well-written" is mandatory. If the code isn't well-written, it will take you a lot longer to figure out. The code I wrote in high school was pretty bad.
Variables should be named to describe what they represent. You should have a reasonable number of comments, not too many or too few (ironically, this amount changes as you get better). Divide your code into manageable chunks and split them into subroutines. Within subroutines, separate the chunks with at least one blank line.
If you want to use the code as in a library, then try not to read the details of it until you really have to. Use the interface or write an appropriate interface for you to use. Work through some examples in the debugger to see what it does.
If you need to fix the code then you need to read the code. I try to focus on just the problem, rather than understand the whole thing. This approach makes it much simpler, I get in and out really quick, just focus on the problem and fix it. If I find something else that's a problem then I look at that too, otherwise I avoid figuring out how the code works.