Um what? I didn't like hide extra meaning in what I said. High quality code doesn't imply all that extra shit you added. It's code that's easy to read and modify. Typically this just means you name stuff well and document things that aren't obvious. Usually my docs explain why something exists since thinking it's unnecessary cause you don't remember what the original problem was a common occurrence before I started doing so.

Is high quality code ran through a formatter? I'd hope so yeah. There should be a consistent code style across the entire project. Doesn't matter what it it long as it's consistent.

100% code coverage is meaningless and as such a pointless metric. Also 100% coverage is explicitly tied to the implimentaion as all code paths have to be reached which is obviously not a good idea (tests have to change when the implimentaion changes as you're testing the implimentaion not the api).

Really a lot of this is just meaningless buzz words as an attempt at some sort of gotcha. Really don't understand how you even interpreted a statement so simple in this way.