An important point of etiquette that has been skipped in the other answers:
Treat it as a suspected bug, and do not assume "I'm right, you're wrong" while presenting your fix.
- No matter how confident you are on the matter, there is always room for having misinterpreted or overlooked something important.
Consider the case of finding an 'error' in code of:
(A + B)
And you decide that all of your use cases need this to be:
ABS(A + B)
Your use cases may not include a need for that possible negative to exist, or even be able to handle it when it does, but that does not mean cases outside of your consideration may not require them.
- Start off with the assumption that the original coders know more about the code than you do. [They might not actually, but opinions of others can always be re-evaluated...]
- Approach it as having a goal of mutually gaining a better understanding of what the code is doing, and what it should be doing, and how it is actually being used.
- Consider phrasing any suggestions for changes/improvements as questions rather than commands. ["Do you see any flaws in my attempt at fixing my problem?" vs "You should use my code instead."]