4 ms·
> Automated refactorings are fast and safe—even when you don’t have tests. Depends on the refactor. At work some people tried to do some automated refactoring
by Zababa 5y ago
> Automated refactorings are fast and safe—even when you don’t have tests.
Depends on the refactor. At work some people tried to do some automated refactoring with Resharper, which changed names of fields of a class, which broke stuff that relied on them for reflection.
- xg15 5y agoI 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.
- Zababa 5y agoFair point, but how does that help existing code?
- enb 5y agoUse nameof instead of a string literal to refer to names of types
- Zababa 5y agoThanks, I'll transmit the advice.
- splittingTimes 5y agoGreat 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.
- Zababa 5y ago> 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.
- splittingTimes 5y agoWe 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.