I break it down into a couple different layers, but I generally think about it in terms of the audience more than just the code itself.
There are some baselines like: bad/inconsistent names make it difficult to understand intent, dead code makes it difficult to understand what is relevant, flaky tests make it difficult to understand what it working.
The next layer is community. You can tell when someone writes Java in Python or vice versa. This isn't always super clear cut and might have layers to itself. For example, JavaScript is definitely #NotAMonolith.
Next is your team. Every team had slightly different norms.
Lastly, I'm starting to think about codebase size as a significant factor. If you are working on something tiny, I think abstraction probably more weight than it is worth. Just writing code as plainly as possible in as few places as possible is a great thing. I think this is particularly valuable while learning a tool. If haven't developed specific habits and for specific problems with that tool, you are not increasing your productivity by adding a lot of poorly understood layers of indirection. Just write the code as plainly as possible in the place you understand as much as possible and develop those solutions as you feel pain. I belabor the point because I used to value "using the framework well" too highly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I break it down into a couple different layers, but I generally think about it in terms of the audience more than just the code itself.
There are some baselines like: bad/inconsistent names make it difficult to understand intent, dead code makes it difficult to understand what is relevant, flaky tests make it difficult to understand what it working.
The next layer is community. You can tell when someone writes Java in Python or vice versa. This isn't always super clear cut and might have layers to itself. For example, JavaScript is definitely #NotAMonolith.
Next is your team. Every team had slightly different norms.
Lastly, I'm starting to think about codebase size as a significant factor. If you are working on something tiny, I think abstraction probably more weight than it is worth. Just writing code as plainly as possible in as few places as possible is a great thing. I think this is particularly valuable while learning a tool. If haven't developed specific habits and for specific problems with that tool, you are not increasing your productivity by adding a lot of poorly understood layers of indirection. Just write the code as plainly as possible in the place you understand as much as possible and develop those solutions as you feel pain. I belabor the point because I used to value "using the framework well" too highly.