Unused class variable warnings
MageJohn opened this issue · comments
Describe the bug
Lots of (about 70) unused class variable warnings.
To Reproduce
Run a scene using the library, e.g. the example from this repository.
Expected behaviour
Ideally these shouldn't appear, as they pollute the output and make it hard to find errors originating from your own script.
Environment:
Manjaro Linux
EDIT: I notice that these warnings are suppressed in the project file in this repo.
Hey @MageJohn, sorry for the late response.
Yeah, there's indeed a lot of warnings, I'm not sure how to go about them for now. On one hand, I'd like to stick as close as possible to the original source code, but on the other hand, I agree, these warnings pollute the output. It's an ongoing issue. I have to dive into the project again and see what can be done about them.
There are several issues open which address warning pollution caused by addons, e.g.:
godotengine/godot#22108
godotengine/godot#28232
One way how to solve this issue is to use the ignore docstrings:
# warning-ignore:my_error_type disables a single warning of a certain type.
#warnings--ignore-all:my_error_type disables all warnings of a certain type in a given file.
#warnings-disable disables all warnings in a given file.
Personally, I think deactivating all warnings is too radical, instead, some errors can probably be ignored individually or on a per-file level.
I had a look at each file and have compiled some insights:
UNUSED_CLASS_VARIABLE: This warning, together with the "shadowing" one, occur the most often. Usually happens with features which were copied from the original or when a property is part of the public API... I think these warnings can mostly be ignored on a file-level or the variables can simply be removed if they are really not necessary.
SHADOWED_VARIABLE: I'm not sure. It can be a real issue, however, they are mostly just used in initialization methods. Another case where I saw a lot of shadowing was in constructs like this:
var state = self.state
Ignoring them either individually or per-file would probably be OK since I have not seen any place where the shadowing would have negative effects.
In my own projects, I use the prefix new_, e.g.: func foo(new_bar): to avoid this issue. But that's not really pretty either...
RETURN_VALUE_DISCARDED: Occurs when the return value of a method is not used. That mostly happened when using calls to OS.execute() or when using connect(). I think these can be ignored on file-level.
UNUSED_ARGUMENT: Should probably be investigated and can be ignored on a case-by-case basis.
UNUSED_VARIABLE: Should probably be investigated and can be ignored on a case-by-case basis.
UNUSED_SIGNAL: Should probably be investigated and can be ignored on a case-by-case basis.
I have also created a PR where I ignored the UNUSED_CLASS_VARIABLE, SHADOWED_VARIABLE and RETURN_VALUE_DISCARDED warnings. The other warnings I left untouched since I feel like we should have a look at them:
#11
Thank you so much for taking the time to work on this @Stoeoeoe. These insights are really helpful.
In the coming weekends, I'll review all the warnings and start silencing those I feel can't be easily fixed (like UNUSED_ARGUMENT warnings coming from the conversion of upstream code). After that, the few remaining warnings should be easy to fix.
I learned something today, as I didn't know Godot supported silencing warning through docstrings. 🙂
Quick question: is putting these docstrings at the very top of the files mandatory or can I move them below the header later on?
See godotengine/godot#33437 merged in 3.2.beta, addons folder will be excluded by default.
Since 3.2 has been released a while ago, I'm closing this issue. Feel free to let me know if you feel it should be reopened.