There is plenty to learn from studying the implementation of a (well-written) library. But read it for learning purposes, not as documentation.
In the case of the STL (which you asked about before), you should never rely on its implementation details in your code. Your previous question implied that you were reading the source code because the documentation "did not provide enough information", and in those cases, no, you're wasting your time. Or even worse, you're actively sabotaging your code by relying on implementation details that are not guaranteed by the library. And that's why you got negative reactions. The STL is carefully designed so that the documentation tells you everything you need to know, and to allow flexibility for the underlying implementation.
So (at least for a well-defined standard library like the STL), feel free to read the code if you think you can learn from it as a programmer. But don't rely on it as documentation.
With less well-specified libraries, it may be necessary to study the source code in order to use the library.
On a side note, typical STL implementation code is not written to be pretty, or to be "good C++ code".
Keep in mind that:
- It is (usually) written with a specific compiler in mind, so it can rely on non-portable extensions and implementation-defined behavior that normal C++ code should not rely on
- It is not written to be read, or to be readable. Once again, the one and only authoritative source of information about your STL implementation is the documentation (most of which is defined in the C++ standard).
- A number of special rules apply for the standard library (not just the STL) - parts of it should be available in both the global namespace and
std
. Parts of it must be callable from C as well as C++. All identifiers used must be taken from special classes of names (generally, leading underscore followed by capital letters, or double leading underscore), to avoid conflicts with names defined in user code.
- They have to react to a number of #defines and configuration options (for example MSVC allows the user to define
_SECURE_SCL
, _HAS_ITERATOR_DEBUGGING
and a number of other macros to control iterator checking, optional bounds checking on vectors and a number of other features.
STL code is typically not pretty, it is not what you should consider well-written code (or at least, if you wrote that kind of code in your application, your code would not be well written. As shown above, the STL implementers had a very different set of requirements than you, as a user of the library)