views:

288

answers:

10

One of the top tips for new programmers is to read programs, like the "old masters" who studied paintings of their ancestors, all programmers should also study programs of their colleagues. The question is, which programs are worth the trouble?

A: 

Start with code you already use. It's easier to get into the code that way because you can already match pieces of code to functionality you know. There's probably some piece of open source software that you use a lot that can get you started.

Other than that it depends on what you want to learn. Find a piece of software where you're unsure of how they did something and try to find out. Its easier to keep motivated to spend the time reading code if the code does something you're actually interested in.

Mendelt
+2  A: 

You might be interested in a book called Beautiful Code where various experts describe their code. There's more information about it on Amazon's page for it here.

ho1
There is also another book called "Code Reading" by Diomidis Spinellis (http://www.spinellis.gr/codereading/). Both led me to the question posted here... .
Mihi
+2  A: 

You can start by reading the source code of the standard library of your programming language of choice. Standard libraries often contain high quality code and also exemplify the correct way to use a particular language.

abhin4v
On the other hand standard libraries often contain performance optimized code. These optimizations may hinder readability and should not be replicated to other code. The optimization for a different usage scenario would be different, most of the time.
mkneissl
A: 

Tough question. One really good idea is to get involved in software that you are interested in. For example, if you like photography, get involved in some open source photo library software. That way you'll find the motivation to stay involved without having to force yourself.

A second bit of advice is to find an active Open Source project. Something that has been around for a while and has at least a few committers. That means that the software is viable and that a number of people have been improving it.

leonm
+4  A: 

Just imagine you opened a book and started to read. If the text is embracing you since the first sentence, you sense quite clearly that there is something here that the author may give you in many aspects.

I think it is kind of similar with reading a code. If you have no clue about the author of the code and after having a short glance on it, if there is something that is valuable in terms of good quality of coding -or even as a bad but teaching example- it will blink an eye to you and you will find yourself reading it.

I think it can be also helpful to read libraries like .Net classes, jQuery etc.

And when you are reading the code written by your colleague, the key point is being objective.

DO not underestimate to come back and read your OWN code time to time. It can be a really good practice to see what you have done in the past that would be done in a different way today.

burak ozdogan
Reading one's one code seems to be a good idea! Thanks :)
Mihi
+1 for reading your own code!
Wim
+2  A: 

Scott Hanselman has a series of blog posts dedicated to some piece of source code to read. Maybe a good idea to start there.

Ronald Wildenberg
+1  A: 

Find the best (or close to it) framework in your language of choice and step through the code. Nothing covers design, organization, naming conventions and best practices like a modern, mature framework.

Manos Dilaverakis
A: 

µC/OS, an embedded real-time operating system, is supposed to be very beautifully written and documented. It's been on my reading list for a while.

Wim
+3  A: 
Norman Ramsey
Great suggestions! Thank you!
Mihi
A: 

Ivan Sutherland's 'Sketchpad' is widely held by many venerable OO programmers to be the epitome of good design. It was a very early CAD program, and was a big influence on Smalltalk and so on, which in turn has been a big influence on OO aesthetics more widely. I think at some point in the '90s OOPSLA or PLoP or some such conference had a workshop on it precisely because it was so well-made.

The only problem is that it's written in some kind of ancient assembly language.

Wikipedia has links, which include his PhD thesis, which i think has a fairly complete description. I don't know where you can get the full source.

Tom Anderson