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.
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.
Comments
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.