I personally started learning how to program by staring at the Quake 3 source code for hours on end.

Looking back on that, I would have been better off with a good book and some exercises. A book is more structured and, if it's a good one, will explain each step of an example in terms somebody new to the concept can understand.

Blindly looking at code *can* teach you some basics but it involves investing way more time than you should have to to understand what's going on. Even then, you'll have to sit through a lot of program crashes until things make sense. Don't do it if you want to avoid headaches :)

Quote:Original post by Joshuad

What I'm gathering is that you are fairly comfortable in C++ but you can't understand what you are seeing when you read others codes. Well, I don't necessarily think anything is wrong with that. Unless it is fairly well documented/commented, it's GOING to be hard to understand in some cases, not many people use the same association when they are naming their classes, objects, etc, and when it is something different than what you are used to doing yourself (again, without proper commenting), you are going to be confused. Length shouldn't be an issue, I think you are just looking at some code that hasn't been explained fairly well.

Comments don't help a reader that isn't familiar with domain idioms.

Someone can be told that library uses prototype objects created by factory, and understand thousands of lines of code. Someone who isn't familiar with "prototype" and "factory" patterns can read tens of thousands of lines of documentation but not be able to make sense of it. Or perhaps that some large block is socket library.

This is why effective libraries follow the Principle of Least Surprise. They are designed in a way that the target audience expects them to be. This audience can be very small, and be expected to have very thorough understanding of much broader or seemingly unrelated concepts.

Physics library usually implies one understands floating point accuracy, numeric stability, O(n) complexity of various tests, topological implications of various algorithms and much more. Even though it will be used by only calling tick() function 50 times a second.

Quote:any tips on reading code faster or easier?

Years of experience of active coding, and studying software design methodologies and idioms. There is no shortcut.

Code is merely implementation of higher level concepts. But implementation itself can be terse or verbose, convoluted or elegant - it still represents same concept.

This is akin to trying to read a book by evaluating a letter at a time. To be effective, the minimum one needs is ability to understand sentences. But to truly understand the message of prose, one needs to be familiar with context, perhaps author's premise, cultural, political or other backgrounds.


This is one reason why different "levels" of languages exist. One line of code in Python can equal 20 lines of code in C++ or 2000 lines in assembly. They carry same message, but one of those is easier to understand than other two.

C++ is also worst of all since due to its flexible and verbose nature, as well as manual resource management concepts, embeds surprising amounts of knowledge into simplest of operations. While assignment operator (=) means one thing in most languages, PhD thesis can be written on full extent and implications of its use in C++.

Quote:but waht about thousands od lines of code

or tens, hundreds thousands or even millions of lines of code.

Any project that large will have some high-level functional structure, which will be briefly described in accompanying documentation, or be implied from the context. User is then expected to be familiar with the domain to understand it.