Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Potential false negative, didn't report error result in unexported method that always returned nil. #21
This issue is inspired by a nice simplification I manually discovered recently, shurcooL/issues@beebdcc.
In it, the method
I was going to open an issue in @dominikh's go-tools repo for consideration, but then realized that this should fit right into
Is this an enhancement opportunity, or am I missing a reason it couldn't/shouldn't have been detected?
I tested with latest
The current reason is because we require at least two return statements to print any "result X is always Y" warning. This is because, sometimes, it's easier to return a constant once than to hard-code it in the caller.
Or, in other words, it often doesn't simplify the code overall to move it from one place to another if it was only being returned once.
However, you could say that
Thanks for the suggestion!
I see, that makes sense. I think I missed this in the README:
However, is that sentence missing a word? "a minimum number of two calls is required..."?
Or is that unrelated to the "at least two return statements" requirement? If so, I think it'd be helpful to document in README alongside with the other conditions.
Indeed, it sounds like this might be worthy of a more specific check/warning, that the returned value is always zero.
referenced this issue
Dec 11, 2017
The README is intentionally vague because the heuristics are changing constantly, and because I don't want users to have to understand them to use the tool. For example, one of these requirements was changed in a3ef08f.
As for the check itself - I had a crack at it last week and had it nearly working, but got stuck on some subtle false positives/negatives. I'll likely give this a second go after the holidays.
I personally still think it's helpful to explicitly document the behavior, even if not in the README, because then it makes it possible to tell whether some behavior one observes is a bug (it doesn't match the documented behavior) or a feature request. Having the implementation be the documentation makes that distinction impossible.
Of course, I realize documenting this is hard and might not be worth the extra effort, so I'm fine with whatever approach you choose for your project.
Perhaps I needed to try that. I don't need it to be very human-friendly, as long as I can understand a reason something is/isn't flagged, it'd be good enough.
Nice, thanks! I'd be curious what those subtle false positives/negatives were, if you have them handy. Otherwise, np.
Sorry about the late reply. I was purposedly ignoring this project for a while, as I got a bit frustrated the second time I tried to write a fix for this :)
That's true - I hadn't thought about bug reporting. Although, if I implemented a proper
Well, that's the thing, it does a terrible job at that at the moment. It tells you what it's doing at every step, instead of what overall decision it made and why. It's written forwards when it should be backwards, if that makes sense.
I'm having another, calmer look at this issue now. I can't remember al the details from two months ago, but I think that the issue that got me stuck is "forwarding return calls", for a lack of a better term.
For example, say that I make it so that
But then, what about:
Which isn't a bad option, but it's certainly a false positive. We don't want to force the user to make this change, as most people will find it intrusive and a net loss of readability/simplicity.
Some examples from the standard library:
You get the picture. It was a coincidence that this false positive was hidden, as my code incorrectly skipped all the nil return values when doing this
Also, a big reason why I failed twice at working on this is because I tried to do too much at once. I was trying to fix the nil bug fixed above, as well as your bug report, as well as the "forwarding return call" false positives. I sometimes forget how important it is to separate issues into little pieces and commits.
Looking to clarify. This issue was marked as resolved in commit ed0d5d5 with the following message:
From that text, it sounds to me like it should now be reporting the code as reported in the original issue (about
Is my understanding wrong, or is there a bug in the implementation?