3 ms·
Agree, but furthermore, it's not only tests that allow you to keep context outside your head, but also compiler errors. On complex tasks for example, calling a
by sideshowb 6y ago
Agree, but furthermore, it's not only tests that allow you to keep context outside your head, but also compiler errors. On complex tasks for example, calling a method that hasn't been defined yet I can offload a subtask from my head because I know for sure the compiler will remind me to implement it later if I forget. Even more explicitly, mid task my c++ can be full of #error directives each with a little note for something to be fixed at that location before I even think about running anything.
- sideshowb 6y agoOr, for that matter, if an entire stack of methods needs modifying to accept some new data type. All you have to do is modify one of them and the compiler won't let you run until you've done the rest. Or modify the type definition and everything using it has to change. If you want to force check every usage, rename the type. Not that I have anything against tests either, these are all just strategies for keeping a record of context.
- RangerScience 6y agoI can see that. I definitely prefer my code to run even while broken, since I find it makes it easier (overall) to write - particularly when I don't have great docs for the data I'm getting from web hooks (I'm looking at you, Slack Actions), where it's useful to just pop into an in-situ REPL and poke around. Although - waaay back in the day, I was very gung-ho about using C++ template shenanigans to enforce code correctness at compile time.
- sideshowb 6y agoIt depends what you're working I guess. I can see where you're coming from with web hooks; in the examples above it was more of a 'pure' algorithm module and much more self contained. Haha, yes I overdid templates for this once too :)