I'd bet you're maintaining legacy C++ code. If so, while it's good to look at good C++ code (like Boost and the materials you can find on the C++ FAQ) chances are you're going to run into some fairly gnarly code--especially if code has been maintained over several years by several developers. Having maintained C++ legacy code in a commercial app for the last 5 or 6 years--I wish I had some good advice to share. There are a few things:
1.) May sound obvious but good version control is essential. A seemingly innocent change can have nasty side effects. You need to be able to revert to a known to be good state easily.
2.) Watch out for side effects. If something looks odd it may be because there was some very valid reason for the odd construct. Some of the developers working on this commercial app decided to add a copy constructor to a class which never had it before. Ironically, when they added a copy constructor, it trounced all over some bitwise copying code that had been hacked in years before. Hence they had to go back to an older version to straighten things out (see point 1 above).
3.) Add intermediate variables to help yourself understand the code. You'll probably see constructs like this:
func1()->func2()->func3();
This means that func1 returns a pointer which is then used to get func2 which returns a pointer which is then used to invoke func3. This is horrid code but it seems to be a very common antipattern in C++ code (at least in my experience). Adding variables to hold intermediate pointers can help a lot in understanding what the code is doing and in checking to insure that you're testing for bad pointers.
Those are just some thoughts off the top of my head.
1.) May sound obvious but good version control is essential. A seemingly innocent change can have nasty side effects. You need to be able to revert to a known to be good state easily.
2.) Watch out for side effects. If something looks odd it may be because there was some very valid reason for the odd construct. Some of the developers working on this commercial app decided to add a copy constructor to a class which never had it before. Ironically, when they added a copy constructor, it trounced all over some bitwise copying code that had been hacked in years before. Hence they had to go back to an older version to straighten things out (see point 1 above).
3.) Add intermediate variables to help yourself understand the code. You'll probably see constructs like this:
func1()->func2()->func3();
This means that func1 returns a pointer which is then used to get func2 which returns a pointer which is then used to invoke func3. This is horrid code but it seems to be a very common antipattern in C++ code (at least in my experience). Adding variables to hold intermediate pointers can help a lot in understanding what the code is doing and in checking to insure that you're testing for bad pointers.
Those are just some thoughts off the top of my head.