"Quality code", in my experience, often means "code that looks like how I would have done it". In other words, it's usually pointless nitpicking and you're better off not engaging in it. Of course, there's some convergence on this topic because certain programming influencers successfully pushed their opinions onto many people who choose not to have opinions of their own which is something that happens in every field because many people find actual independent thought hard or scary.
There are some things that genuinely matter such as minimizing repetition, using variable names that are clear/easily searchable with "find" (meaning without tons of false positives) and not writing undebuggable code if you can avoid it[0]. I also think performance matters even if it seems fast enough on your machine. In my view, you shouldn't use Integer instead of int in Java unless you absolutely have to because Integer wastes resources creating an object containing an int and dramatically increases cache misses[1]. But in general, it isn't worth worrying about unless you can actually come up with a coherent explanation of why your preferred way of writing code will make the software perform better or be easier to maintain. Of course, the only absolute rule in code is that there's always an exception to every rule.
[0]: I'm generally in the "C/C++ macros considered harmful" camp especially when they resemble functions and feel similarly about anything else that makes the code execution path less than straightforward to follow.
[1]: I have a strong suspicion that OOP itself is an anti-pattern and that the entire paradigm is a wrong turn that needs to be abandoned. It's weird because I had a favorable opinion of OOP before I learned what it is in college but it tripped my brain's BS alarm. But I've never worked in a large enterprise environment so I haven't actually seen it in practice enough to fairly evaluate it.