How about you break out your "Look for CRC code match in packet data" loop into a boolean function called "PacketContainsCRCCode"? The rule of thumb that I lear

How about you break out your "Look for CRC code match in packet data" loop into a boolean function called "PacketContainsCRCCode"? The rule of thumb that I learned early on, and that I try to apply, is that comments should answer the question "why," not "what." "What" is easily answered by naming your methods (and variables, should you be forced to use them). I know what you're getting at. There's nothing worse than reading a 50-line function with no comments. But the real WTF isn't the lack of comments - it's having a 50-line function in the first place (or 8000 lines for that matter). Having lots of comments is a code smell - it indicates poorly factored code. Next time you need to write a comment explaining what a piece of code is doing, try writing a function instead, with a name that says what it's doing, and see where that takes you. I highly recommend Misko Hevery's "Clean Code Talks" on YouTube. They're part of the Google Tech Talks series, and they will blow your mind if you let them.