2 ms·
Not quite. If I was to truly critique the example, the problem lies mainly with the ban function, which appears to allow ints to be passed in as arguments. If w
by osrec 9y ago
Not quite. If I was to truly critique the example, the problem lies mainly with the ban function, which appears to allow ints to be passed in as arguments. If we have static typing available to us (the example in the article doesn't seem to), then yes, I agree we should ensure that only the relevant type should be allowed as the argument. But still, problems can lurk in the shadows, for example, you could initialise a User type with a message ID by mistake, or even an iterating int, much like the example in the article. I'm not trying to be difficult or unnecessarily contrarian, but my experience tells me that you can put a whole bunch of safeguards into your code, but nothing beats testing at catching bugs, and sometimes, the safeguards are not worth the efficiency hit. Worse still, the safeguards can at times provide a false sense of security.
- tom_ 9y agoIt shouldn't be an excuse to dispense with testing altogether, but static typing is certainly superior to testing for certain classes of bug. The compile-time checks prove certain types of defect simply don't exist, which is the kind of guarantee no amount of testing can give you in that respect for any useful program. As for the initialisation problem, it's true that it can't be structs all the way down, and at some point you will have to create one of these objects, probably from a primitive with a non-meaningful type such as int, or string. But my experience is that IDs and the like tend to be created in a small number of places, and then reused, copied and passed around. Far easier to find and check all the places where one is created than all the places where one is used!