4 ms·
Most static code analysis tools I've used allow you to write exceptions for rules into your code using comments that follow a particular signature. Isn't it su
by CivBase 6y ago
Most static code analysis tools I've used allow you to write exceptions for rules into your code using comments that follow a particular signature. Isn't it sufficient to just ban the use of random() and require devs to use one of those comments to effectively "sign off" on it if they encounter a good use case?
- Macha 6y agoThere's two trains of thoughts here: 1. You can disable lint warnings, so it's no big deal if some rules have false positives 2. Disabling lint warnings should be a code smell, so if there's some rule that's getting people used to disabling lint warnings, it is a problem. I'm on camp 2 on this rule.
- rightbyte 6y ago> Disabling lint warnings should be a code smell I believe lint warnings are for pointing out unusual constructs that might be a mistake not to be a code police.
- account42 6y ago> Fix Rate is the percentage of merge-blocking findings that are fixed (i.e., not muted*) in CI. We believe this is a proxy for engineering value. As we run our own developer-focused security programs, we’re obsessing over how to increase the Fix Rate for the rules on our projects. > Observing a bad 0% Fix Rate for random() (with only 7 data points from our projects), we decided to silence the rule for r2c developers
- CivBase 6y agoI wouldn't necessarily consider a fix rate of 0% to be bad. If you're doing something that looks bad, you should probably leave a comment that silences the static analysis error and justifies why you're doing it. If that justification is missing, the static analysis tool should flag it IMO. If using random() in a crypto project is a bad code smell, then I'd say every use of it should come with a brief justification.