4 ms·
Const for things that locally never change. I also would not fight const whenever possible. Lots of data is not intended to be mutable, even if it lives within
by MattGaiser 2y ago
Const for things that locally never change. I also would not fight const whenever possible.
Lots of data is not intended to be mutable, even if it lives within an object and there are business reasons for that. I find the restrictions above ideologically purist over practical, like the devs who insist that private/internal methods should not have unit tests.
Const literally always means reduced readability and sometimes a lot of extra code.
- taylodl 2y ago> like the devs who insist that private/internal methods should not have unit tests Because unit tests for private/internal methods aren't required. They are tested via the testing of the public methods. If a test coverage analysis reveals that your private/internal methods weren't fully tested, then that tells you one of two things: 1. Your public methods weren't fully tested. Your test coverage analysis should reveal if that is the case. 2. Your private/internal methods were overengineered. They include functionality that isn't being used. Both of these are problems, but problems of a different kind. You shouldn't ignore (1), but (2) can be addressed in a myriad of different ways - including not addressing it. (2) is indicative of a development process issue more so than a defect in a development artifact.