As others have mentioned, you should ask about the senior developer's choices in a non-confrontational way, but it might also be worth it to look into a few things.
First of all: is there a coding standard that the project follows? If there is no coding standard defined, then nobody is breaking the coding standard. The 'standard' may simply be to make new code look similar to the old code. That's an unfortunate position to be in, but an ad-hoc coding standard is still a coding standard.
If there is a coding standard: who ensures its implementation? Are all developers responsible, is it handled during review periods, etc.
I'll give you my example: I came onto a project that's just starting out. We have senior members, but mostly juniors(myself included). As it turned out, I was the one who was most concerned about a coding standard. Our company and QA policies dictate that we have a standard, and since I was the one who brought it up it was my job to find one.
That turned out to be super easy. There's a standard for Java set by Oracle, which makes that the obvious choice. Next, I found a tool for Java called Checkstyle, which enforces coding standards for you. Every time you make a change and save a file, Checkstyle runs over the file for any violations of the coding standard you have, and high lights all violations just like a warning. Additionally, it does a few static analysis tasks: N-Path complexity, cyclomatic complexity, etc. After that, I looked into Eclipse's formatter and found I could make that conform to our coding standard as well. So now, after a minimal amount of set up, we have a tool that:
- High lights coding standard violations
- A formatter that can be invoked with
ctrl + shift + f
- Zero maintenance
- No time is spent in code reviews for trivial coding standard issues(tab here, space there, comment needed here, etc)
So, ultimately, to really deal with maintaining a coding standard, I would:
- Ask what the current standard is, is it defined somewhere, and are all developers aware of it?
- Get a plan ready - do some homework and search for tools in your project's language that can help you do what I did. Seriously: having a coding standard in place that everyone follows is great. I ended up making it so easy to do that no one had a reason not to follow it.
- Once you have a plan, try talking about it to your supervisor. Tell them your plan, and more importantly: tell them how this could save them time in the future by having fewer defects in the code.