4 ms·
Putting it in liberal/conservative terms moves it to a simple matter of opinion. But most code spends most of its life maintenance. Would anyone argue against t
by cturner 5y ago
Putting it in liberal/conservative terms moves it to a simple matter of opinion. But most code spends most of its life maintenance. Would anyone argue against the importance of maintenance?
- rgoulter 5y agoI think it inevitably comes down to trade-offs. If you can write highly maintainable code without paying the cost of slower speed, surely that's a winning strategy. But I suspect an increase in maintainability means "more friction to change". (e.g. I'd expect adding documentation and unit tests is to take more time in the short term than just writing the code without documentation and unit tests).
- jatone 5y agothis problem is precisely what tooling is for. golang for example solves the explicit import problem quite nicely with almost no friction outside of ambiguous cases, which you'd need to handle explicitly anyways.
- rgoulter 5y agoI think golang makes for an interesting example: Your program won't compile if you have unused imports, or even unused variables. Which is low-friction for maintenance. You're not going to have to worry if deleting something is unsafe. But this strong-arm implementation of a lint means that iterating on code meets high friction. It slows down developer iterations as you have to comment/uncomment in order to compile. -- "But if you use some tool it's not so bad" is advice I've been given, which strikes me as the same as "automatic loading isn't so bad if you're using an IDE".