My experience is exactly the opposite. I don’t work for a FAANG but I’ve been around the block a bit. Its always the junior devs that try and add new warnings etc to the code base. I always require warnings to be cleaned up even if that means disabling specific instances (but not the whole rule) because the rule is flagging a false negative.
That’s why I said false negative. The medical test is testing for the presence of a disease. So if they find the disease is considered a positive test (it found what it was looking for). For static analysis on code, its the opposite. Its testing if your code is free of issues that it can detect. If it finds no issues, then the test was positive. If does find issues, the test failed and each issue is a negative that contributed to the test failing.
You could say “A static analysis tool is testing for the for the presence of defects” or “a medical test is testing if your body is free of diseases that it can detect” to change how you’re looking at either of the tests in the previous comment.
By your logic it would be a positive for your code to have errors/warnings. And on the latter, that would appropriate if there was a test that determined if you are free from all known diseases (or at least those that it can detect).
I’m not debating. It is not a matter of opinion. I’m doing you the courtesy of informing you how the entire rest of the world uses the term.
If action A looks for thing X, and it finds thing X, then the test is positive. If action A fails to find thing X, then the test is negative.
If action A claims to find thing X, but later confirmation determines that thing X is not really there, then this situation is called “false positive”.
If action A claims fails to find thing X, but later confirmation determines that thing X is actually there, then this situation is called “false negative”.
That thing X may subjectively be considered an unwanted outcome has **nothing ** to do with the terms used.
It boils down to desensitization/normalization. Warnings (and errors, of course, but tests as well) exist for a reason. If you don’t care about these gauge constructs are telling you, then they have no real diagnostic value. Getting into a place where you’re not looking at how your systems are actually running is generally a bad idea, especially in the long run.
My experience is exactly the opposite. I don’t work for a FAANG but I’ve been around the block a bit. Its always the junior devs that try and add new warnings etc to the code base. I always require warnings to be cleaned up even if that means disabling specific instances (but not the whole rule) because the rule is flagging a false negative.
false positive?
Warnings and errors are negatives not positive. So if it generates a warning that is OK, it’s a false negative.
Just so you know, if your doctor calls and tells you that your HIV test is positive, you probably shouldn’t run out and celebrate.
That’s why I said false negative. The medical test is testing for the presence of a disease. So if they find the disease is considered a positive test (it found what it was looking for). For static analysis on code, its the opposite. Its testing if your code is free of issues that it can detect. If it finds no issues, then the test was positive. If does find issues, the test failed and each issue is a negative that contributed to the test failing.
You could say “A static analysis tool is testing for the for the presence of defects” or “a medical test is testing if your body is free of diseases that it can detect” to change how you’re looking at either of the tests in the previous comment.
By your logic it would be a positive for your code to have errors/warnings. And on the latter, that would appropriate if there was a test that determined if you are free from all known diseases (or at least those that it can detect).
I’m not debating. It is not a matter of opinion. I’m doing you the courtesy of informing you how the entire rest of the world uses the term.
If action A looks for thing X, and it finds thing X, then the test is positive. If action A fails to find thing X, then the test is negative.
If action A claims to find thing X, but later confirmation determines that thing X is not really there, then this situation is called “false positive”.
If action A claims fails to find thing X, but later confirmation determines that thing X is actually there, then this situation is called “false negative”.
That thing X may subjectively be considered an unwanted outcome has **nothing ** to do with the terms used.
It boils down to desensitization/normalization. Warnings (and errors, of course, but tests as well) exist for a reason. If you don’t care about these gauge constructs are telling you, then they have no real diagnostic value. Getting into a place where you’re not looking at how your systems are actually running is generally a bad idea, especially in the long run.