Greg Wilson often mentions that very few programming courses will incorporate the study of existing, proven programs and their code. This probably applies equally to self-taught programmers, and many programming books.

I recently bought and read Wilson's recent publication, The Architecture of Open Source Applications (http://www.aosabook.org/en/index.html). It focuses more on the architecture design for some well-known programs (Eclipse, Sendmail, Mecurial et al), but does include some code samples. The best aspect of it, IMHO, is that it focuses on the decisions the programmers faced when designing their code, and the tradeoffs they made.

The NoSQL chapter, in particular, is a really good read and should be referred to by all parties before any NoSQL / SQL flamewar begins.

Seconding my sibling richchan that it doesn't necessarily need to be "good" code, I'd suggest starting by reading the libraries — or even just the specific classes or functions — you like to use.

You already know what they're supposed to do, so they'll be a lot easier to figure out at first— and once you do, it will provide the immediate benefit of understanding your tools.

As for how you tell, a good rule of thumb is, the harder of a time you have telling how it works, the worse the code is. This is of course only a rule of thumb, but it applies doubly in the case of code where you understand well what it's supposed to be doing.

Sometimes this is a rather advanced project. Don't expect to have an easy time reading glibc, for instance.

Yeah, this is probably better the higher-level you're talking about. Also, I wouldn't start with standard libraries, since they'll generally be written much more for performance than accessibility.

There are many ways. One example:

On GitHub click on Explore GitHub, Languages, your language, "most forked overall" and choose what interests you.

Or in other words look up popular programs written in the programming language of your choice. Just be sure to not look at code that's too old, as it's more likely that they contain a lot of stuff you wouldn't do anymore. Especially true in the Perl world.

It probably doesn't even need to be "good" code. Just study any code and think about why it is written that way, and what circumstances makes it good.

Any correctly written code can probably be considered good. The rest is about how well it is designed and how it performs in different situations.

There are plenty of good code around. Study Linux Kernel if you want to get really high!! Basically, depends on where your interest lies .. find a good open source project in your area of interest and figure out how it works ...

Exactly. It depends upon which language, framework, programming style, etc. For game code you can look at ID's work. For java I hear the Jenkins code is very good. Ask around, there is no shortage of good code.

My point is that as an apprentice you should study the masters. Try and duplicate their work through practice.

Jenkins code is alright. It has a little bit symptoms of "being written by one man" (Kohsuke) to it but I wouldn't call it very good.

Here are a few projects with good Java code: Spring Framework (check mostly around the spring-core stuff), Apache DS, Google Web Toolkit APIs, Google Guava, Google Guice (pretty much almost all Google Java open source projects have similar high-quality).