You say you are strict with code quality, but you are not in charge, so that doesn't matter from the company perspective.

What matters is the company's stance on code quality.

If there is a strict company policy, you can use that to back any discussion with your coworker, but trying to go to your supervisor will create a ton of conflict, so it's best avoided for general style concerns which won't lead to disaster.

If there isn't a strict company policy on this, the only things I'd even consider bringing up (with either your coworker or supervisor) are things that are likely to or have in the past led to the code breaking.

First approach your coworker. Do not tell him the way things need to be (because you should not assume you know better, and there's no faster way to make someone defensive). Ask him his reasoning behind doing it his way and respond with an argument addressing the problems with that, if you can find any (perhaps he has a good reason for doing things the way he does).

If that doesn't work, you can consider bringing this up with your supervisor.

Don't be accusatory or even mention the other team member at all - just bring up any one of the issues and point to one or two examples in your code base, and proceed with the same humble approach mentioned above.

Your supervisor might check or ask you to check who wrote the code (if possible) and this might lead to your supervisor addressing the issue with said coworker. But all of this would be at the discretion of your supervisor. Yes, this might lead to your coworker thinking you "ratted him out", so proceed at your own risk.

Coming from an experienced programmer, all of the things you say should ideally be avoided, but none of them are necessarily at the "WE'RE ALL GOING TO DIE!" severity. Ignored exceptions or missing null checks can be disastrous, but they can also sometimes be functionally unnecessary or intentionally omitted. Naming of classes doesn't affect execution at all in any language I know of (reflection notwithstanding) and is generally entirely opinion-based.

If you consider all 3 of those things to be roughly of the same severity, you may want to hold off on saying anything until you no longer do.

You say you are strict with code quality, but you are not in charge, so that doesn't matter from the company perspective.

What matters is the company's stance on code quality.

If there is a strict company policy, you can use that to back any discussion with your coworker, but trying to go to your supervisor will create a ton of conflict, so it's best avoided for general style concerns which won't lead to disaster.

If there isn't a strict company policy on this, the only things I'd even consider bringing up (with either your coworker or supervisor) are things that are likely to or have in the past led to the code breaking.

First approach your coworker. Do not tell him the way things need to be (because you should not assume you know better, and there's no faster way to make someone defensive). Ask him his reasoning behind doing it his way and respond with an argument addressing the problems with that, if you can find any (perhaps he has a good reason for doing things the way he does).

If that doesn't work, you can consider bringing this up with your supervisor.

Don't be accusatory or even mention the other team member at all - just bring up any one of the issues and point to one or two examples in your code base, and proceed with the same humble approach mentioned above.

Your supervisor might check or ask you to check who wrote the code (if possible) and this might lead to your supervisor addressing the issue with said coworker. But all of this would be at the discretion of your supervisor. Yes, this might lead to your coworker thinking you "ratted him out", so proceed at your own risk.

Coming from an experienced programmer, all of the things you say should ideally be avoided, but none of them are necessarily at the "WE'RE ALL GOING TO DIE!" severity. Ignored exceptions or missing null checks can be disastrous, but they can also sometimes be functionally unnecessary or intentionally omitted. Naming of classes doesn't affect execution at all in any language I know of (reflection notwithstanding) and is thus much less severe than the above concerns which can cause problems at runtime, and it's also generally entirely opinion-based.

So I feel it hurts your argument to put all 3 of those things at roughly the same severity.

But you're certainly free to refuse to work in an environment that doesn't meet your standards and escalate any style concerns as though it were life-threateningly serious.