In General: Learn from the Contrast

I think it’s important to both read good and bad code.

If you read ONLY crap code, you probably won’t learn much from it. If you read a mixture of good and bad code, you’ll probably learn more from it. The good code is supposed to teach you new things, the bad code to show you the general mindset of the average programmer and the pitfalls to avoid, and to make you realize how much effort can be saved with good code.

The contrast is very important in helping.

Similarly, for a different domain, Stephen King says in his memoirs on writing that recommends to read bad novels. You can’t appreciate the good ones if you don’t read bad ones, and there’s a whole breadth and range of ways to approach writing. You might be surprised by what you find in the bad ones.

That being said, don’t spend your life reading code that looks like it’s been written by a herd of monkeys or bored students with no interest in learning programming and who just an one CS elective (except if that’s your job, then it’s helpful to learn their common errors and to understand why they occur frequently).

It’s very important to compare and contrast. For instance, take the source code for the 3 major BSD systems: NetBSD, OpenBSD and FreeBSD. They are very similar, yet their implementations of even the simplest tools differ (ls, cat, etc…). And surely there’s one you’ll prefer over the other (haven’t checked for about 8 years, and not wanting to be judgmental here, I just want to give a personal experience, but at the time the OpenBSD code struck me as largely more elegant than the others, and the NetBSD code to be quite instructive to learn about using macros and pre-proc guards).

For In-House Code: Learn from the Context

You mention that it’s about reading code written within your company as well. In this case, I’d say it’s even more important to read some of it. It’s very interesting for you to get an understanding of the team’s mindset by looking at the code, but it will also give you a deeper understanding of how your programs work.

Finally, there’s a very historical component to it. Don’t just read the current codebase. Give your favorite SCM client at hand and lurk through the timeline of the codebase. It’s sometimes very interesting to see why a code became to be what it is now. It can have gone through the hands of a dozen different programmers of different age, or you can even see that a single programmer might have matured over time. It also teaches you about certain “oddities” and mean sneaky bugs they might have encountered and why they chose an approach over another, even if seemingly less elegant.

It gives you context.

Yes, definitely. Studying and understanding other peoples code is absolutely essential in order to grow as a programmer.

In a general sense, it is always good to study and understand other peoples code, even code which is not part of the system your are working on. This will help you to see things which are good and bad in your own system, and inspire you to think up new and better ways to improve your own code.

Having a basic knowledge of the entire system you are working on — not only the components you are responsible for — is important in order to know how you can interact with other parts of the system.

Nice question, Each programmer/developer can write code in their own ways and learned ways. Learning/analyzing other’s code is one of the reason to become a better developer. In others code

1. somebody follows coding standard
2. somebody follows junk code
3. somebody follows short codes like in framework
4. somebody follows all of the above

Learners types:

1. Listening learners

2. Seeing learners

3. Touch / experience learners