Ask HN: How to deal with well-intentioned PR comments?

Our team just got a new (senior) team member. He's nice and he knows a lot. Our codebase is not the best codebase out there (we know that), and we do mix certain best practices from here and there (clean code, separation of concerns, solid, DI, modularization, etc.)... but we are far from following "by the book" the most popular practices our there. This fact doesn't slow us down and we pretty happy with our current "architecture" (features are pushed fast, bugs are fixed in an isolated way, performance has scaled nicely, etc.), and we are certainly open for suggestions on how to improve our codebase, of course.

Now, our new team member suggests in PRs things like the following:

- "let's rename that class to X so that it includes the suffix Y because of reason Z". This suggestion makes totally sense... but in our codebase our classes have already a certain naming convention that doesn't go the way our new team member thinks is best.

- "following SOLID principles, class X should be splitted in two because of reason Z". Again, the suggestion makes totally sense, but if we follow it, it would make class X a snowflake in our codebase.

The worst thing is that our codebase is not in a bad shape, so his suggestions, while definitely well-intentioned and correct in most software engineering books, lack context and would make our codebase not necessarily better. There is, of course, the possibility to refactor our entire codebase to follow the best practices out there, but we think that will give us little to no benefit (also, it will take time and it will be hard to argument this kind of decision to management because, as I said above, it's "working fine")