241–250 of 327 posts
Earlier quoted context omitted.
“Program testing can be used to create 1 the presence of bugs, but never to show their absence” 1) edited
That is wrong in general. With enough tests you absolutely can show the absence of bugs for certain programs. It is for example easy to test „hello world“ exhaustively.
[0]: https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...
Earlier quoted context omitted.
I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…
> I strongly prefer the explicitness I have a rule for my teams: "Don't write clever code". I try to constantly reinforce that we don't write code for ourselves, we write it for the next person. We should be doing everything in our power to decrease their cognitive load. I try to envision the person that comes after me (who may be me in months or years!) and imagine that they are having a Bad Day and they have to mak…
Earlier quoted context omitted.
I assume no and ultimately that is the point of code like this. As you say, if you can somehow correctly identify every possible branch in your tests then you could write the actual code any way you like. But then the tests would have to look like this, otherwise you'd have abstraction in your tests and you couldn't be sure if it covers every branch. Who tests the tests?
You test the test by mutating the code. Once you have 100% condition/decision branch coverage you can automatically sweep the code with changes and the tests will fail. I have a little harness I use for this steps through each non-comment line of code changes signs, comparison directions, offsets values, swaps variables, adds negations, replaces computations with constants, etc. basically changes that are more or les…
I think the problem is you are then moving your "real" condition/decision branch documentation into your tests. The tests are then basically a guard rail for just in case someone modifies some abstract bit of code and it changes the behaviour of some otherwise opaque decision branch. The approach in OP seems to be to just move the "real" logic/documentation into the code itself and do away with the abstractions (and perhaps the tests too).
// CSINameTranslator can get the CSI Driver name based on the in-tree plugin name type CSINameTranslator interface { GetCSINameFromInTreeName(pluginName string) (string, error) } Do people actually find comments like the above useful?
Earlier quoted context omitted.
That is wrong in general. With enough tests you absolutely can show the absence of bugs for certain programs. It is for example easy to test „hello world“ exhaustively.
Let's say you've tested this thing 1 million times. Each time the output was automatically checked by five different and independently-developed test suites. You're ready to swear there's no possible way for it to fail. And then someone tries it with a ulimit of 16kB. Does it run? Do you _know_? Do you even know what is correct behavior in this situation?
Earlier quoted context omitted.
That is wrong in general. With enough tests you absolutely can show the absence of bugs for certain programs. It is for example easy to test „hello world“ exhaustively.
Spoken like someone who has never had to deal with undefined behavior corner cases.
Earlier quoted context omitted.
If the 'if' condition matching always results in a thrown exception, a return, or likewise, then you don't really need an 'else' unless you're using a language which supports conditions and resumption (conformant Common Lisp implementations, and not really anything else I know of). The 'else', implicitly, is that the flow of control leaves the scope of the 'if' block at all. (I haven't read far enough into the code t…
Swift's "guard" statement would be pretty handy here.
if (foo) {
bail out
}
https://en.wikipedia.org/wiki/Guard_(computer_science)
Swift has a guard keyword, but the construct feels a little awkward given most languages do the above. It makes me do a double take.
guard !foo else {
bail out
}