-
-
Notifications
You must be signed in to change notification settings - Fork 915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unused code report #2308
Comments
That's it! I'm truly impressed, considering the amount of code you have 🚀 |
Good stuff, all the extra test helper fields can be removed at least I think. For flame_bloc I think @erickzanardo or @wolfenrain for example would have to check and for Jenny I'm guessing that it should stay, but @st-pasha can hopefully verify that. |
Here is the reason why I love gamedev, The method I will try get to the flame bloc part this week :D |
…ctor_test.dart (#2379) This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. This one was a no-brainer -- the variable was clearly replaced by specific counters during the writing of the test and forgotten there: int nOnTapDown = 0; int nOnLongTapDown = 0; int nOnTapUp = 0; int nOnTap = 0; int nOnTapCancel = 0; It wasn't even increment and the taps are already thoroughly tested more granularly
This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. In this case, we have a test helper, which is a public function we expose to help people write better tests. Which means that the function could be useful, it was just lacking a test -- so I added it. That being said, if this method is deemed unnecessary for users, I can just remove it instead - lmk.
This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. In this case, the unused code is in the tests, which likely means it is indeed necessary. I tried to infer the intent of the author here, and even considered adding the names of the components to the events, but the events are already always per component, so that was meaningless. I also thought it might be a missing toString, that they would wish to show the component name for debugging purposes, but I didn't see any asserts/logs on the component objects themselves (just the events). So I concluded there is no reason to keep this field, but lmk if anyone disagrees and I can bring it back and add some function to it.
…ample (#2380) # Description This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. Since this an example package, it definitely should never have unused code. In this case, the constructor wasn't being used, but upon deeper investigation, that was because this particular event wasn't ever fired at all. So I removed it entirely. If this was supposed to be fired somewhere by the example, please lmk and I can add the missing firing. But as far as I can see, the event serves no purpose in this example. ## Checklist - [x] I have followed the [Contributor Guide] when preparing my PR. - [x] I have updated/added tests for ALL new/updated/fixed functionality. - [x] I have updated/added relevant documentation in `docs` and added dartdoc comments with `///`. - [x] I have updated/added relevant examples in `examples` or `docs`. ## Breaking Change? - [ ] Yes, this PR is a breaking change. - [x] No, this PR is not a breaking change. <!-- Links --> [Contributor Guide]: https://github.com/flame-engine/flame/blob/main/CONTRIBUTING.md [Conventional Commit]: https://conventionalcommits.org/ [CHANGELOG]: https://github.com/flame-engine/flame/blob/main/CHANGELOG.md Co-authored-by: Lukas Klingsbo <me@lukas.fyi>
…rovider_test.dart (#2381) This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. In this case, it is a test file, so there should definitely be no unused code. However analyzing the unused code revealed to me some intent of testing multiple subsequent state changes (dead -> raise from dead). I believe such test was missing entirely, so I added it. I think it holds value, but lmk if you disagree I can just delete the test and the method.
…ctor_test.dart (#2379) This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. This one was a no-brainer -- the variable was clearly replaced by specific counters during the writing of the test and forgotten there: int nOnTapDown = 0; int nOnLongTapDown = 0; int nOnTapUp = 0; int nOnTap = 0; int nOnTapCancel = 0; It wasn't even increment and the taps are already thoroughly tested more granularly
This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. In this case, we have a test helper, which is a public function we expose to help people write better tests. Which means that the function could be useful, it was just lacking a test -- so I added it. That being said, if this method is deemed unnecessary for users, I can just remove it instead - lmk.
This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. In this case, the unused code is in the tests, which likely means it is indeed necessary. I tried to infer the intent of the author here, and even considered adding the names of the components to the events, but the events are already always per component, so that was meaningless. I also thought it might be a missing toString, that they would wish to show the component name for debugging purposes, but I didn't see any asserts/logs on the component objects themselves (just the events). So I concluded there is no reason to keep this field, but lmk if anyone disagrees and I can bring it back and add some function to it.
…ample (#2380) # Description This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. Since this an example package, it definitely should never have unused code. In this case, the constructor wasn't being used, but upon deeper investigation, that was because this particular event wasn't ever fired at all. So I removed it entirely. If this was supposed to be fired somewhere by the example, please lmk and I can add the missing firing. But as far as I can see, the event serves no purpose in this example. ## Checklist - [x] I have followed the [Contributor Guide] when preparing my PR. - [x] I have updated/added tests for ALL new/updated/fixed functionality. - [x] I have updated/added relevant documentation in `docs` and added dartdoc comments with `///`. - [x] I have updated/added relevant examples in `examples` or `docs`. ## Breaking Change? - [ ] Yes, this PR is a breaking change. - [x] No, this PR is not a breaking change. <!-- Links --> [Contributor Guide]: https://github.com/flame-engine/flame/blob/main/CONTRIBUTING.md [Conventional Commit]: https://conventionalcommits.org/ [CHANGELOG]: https://github.com/flame-engine/flame/blob/main/CHANGELOG.md Co-authored-by: Lukas Klingsbo <me@lukas.fyi>
…rovider_test.dart (#2381) This is a cleanup identified on this issue: #2308 Using an amazing unused-code tooling Now, since Flame is a public API, unused code might not be trivial - it might just mean untested code. In this case, it is a test file, so there should definitely be no unused code. However analyzing the unused code revealed to me some intent of testing multiple subsequent state changes (dead -> raise from dead). I believe such test was missing entirely, so I added it. I think it holds value, but lmk if you disagree I can just delete the test and the method.
That was the last one ;) |
Closing it as we merged everything! 🎉 |
Hi! I'm testing new
check-unused-code
command implementation that can find separate methods, fields, etc.In this issue I'll list all the reported files and then we can decide how (if should) they will be removed (by me, by you, etc).
If you're not interested, feel free to close this issue 🙂.
Report output for
packages/flame/
folder:Report output for
packages/flame_bloc/
folder:Report output for
packages/flame_jenny/jenny/
folder:The text was updated successfully, but these errors were encountered: