> Bad abstractions and models make it much harder to understand code, though.
True! The point I'm trying to make is more that code clarity is important and worth striving for, regardless of the means you use to achieve it. Clarity is a non-negotiable part of my definition of "nice". If it's also part of others' idea of "nice" -- especially those of novice developers who look to more experienced developers for guidance -- then this paragraph might suggest that clarity can be down-played. It can't.
If you're an experienced developer, you should be able to find good abstractions for achieving clarity in-context. But novice developers can still identify code that's unclear (to them, especially).
Blindly applying abstractions rarely helps with code clarity. Some developers apply certain abstractions because "it's a best practice", rather than because it's actually more clear. That's definitely not what I'm advocating for.
True! The point I'm trying to make is more that code clarity is important and worth striving for, regardless of the means you use to achieve it. Clarity is a non-negotiable part of my definition of "nice". If it's also part of others' idea of "nice" -- especially those of novice developers who look to more experienced developers for guidance -- then this paragraph might suggest that clarity can be down-played. It can't.
If you're an experienced developer, you should be able to find good abstractions for achieving clarity in-context. But novice developers can still identify code that's unclear (to them, especially).
Blindly applying abstractions rarely helps with code clarity. Some developers apply certain abstractions because "it's a best practice", rather than because it's actually more clear. That's definitely not what I'm advocating for.