> (A) assume the comments are correct and skip reading what the code does?
Yes, unless I was working on that particular piece of code. There's often far too much code in a code base to waste time reading it all, and reading the comments can provide quick understanding.
> The first seems awfully risky to me and poor advice to any programmer trying to write solid code.
Why? Bad code is bad code. Writing bad comments (or no comments) means you're writing bad code. Don't write bad code, and then write documentation to help yourself think through why it's not bad code, and tests to both help you think through it, and verify that it's not bad.
(A) assume the comments are correct and skip reading what the code does?
(B) use comments as guidance and read code anyway?
The first seems awfully risky to me and poor advice to any programmer trying to write solid code.