I think that's more an argument against using reflection though. If you use reflection, you're effectively changing the rules of the language. No automated tool will be reliable after that.

Fair point, but how does that help existing code?

Great point. We use method/class names in config files that get parsed and dynamically evaluated. You could break the whole application by changing class names as an init config could fail.

Also persisting stuff in customer DBs that depends on class names (and reflection) is nice source of terror. Shipping a new version of your software with a refactored class names corrupts the whole DB of a customer.

> Also persisting stuff in customer DBs that depends on class names (and reflection) is nice source of terror.

We do that but with XML files, most of our tables are dynamically generated. I'm a bit scared every time I touch this part.

We have a whole framework that handles migrations of costumer DBs after updates. But when you don't even know that your changed class gets persistent (because of spaghetti inheritance/type hierarchy) and you do not enter it in the migration scripts, you duck up.

Use nameof instead of a string literal to refer to names of types

Thanks, I'll transmit the advice.