Better linting rules 1 #98
Conversation
This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final: WorkoutForm._plan
info: Prefer const with constant constructors. prefer_const_constructors
|
Now only four hints are left in the analyzer: I dont know if the not used vars are planned to be used so I left them in and the other two are some flutter things which got deprectaed lately but I left them in for now since we are using a hybrid flutter version. |
|
|
||
| static const daysToCache = 7; | ||
|
|
||
| static const _exerciseInfoUrlPath = 'exerciseinfo'; |
There was a problem hiding this comment.
quick question, why did you remove the underscore? Since this isn't a library, we know that we'll be not misusing methods or properties but if it's clear they are only meant for "internal" consumption, why not mark them as such?
There was a problem hiding this comment.
I myself was confused why the analyzer complained about it. But it turns out that static variables cannot be private. (Couldn't find anything online about it but a short dartPad test proved this thesis). We can of course remove the static modifier instead of the _, but at that time I haven't thought about that.
There was a problem hiding this comment.
Ahhhh. I guess it kinda makes sense.
And in our case, in the end it doesn't really matter, they are constants anyway
|
thanks again for another herculean PR ;) the ones for the exercises will be removed, we're refactoring that part in another branch anyway. If the other one isn't used then they can be removed |
|
@rolandgeider I think I haven't understood you right, should I undo the changes in the exercises or will they just be overwritten Also we had merge conflicts in the pubspec.lock file I fixed them manually, hopefully nothing broke Edit: CI came to the tests so we should be fine |
|
I meant that we can remove the exercises variables since they will be reworked anyway, I can do that |
|
@rolandgeider you should have write access to my branch feel free to edit things |
|
Will do, thanks! |
For #87 cf: #86
I updated some further linting rules and updated the code accordingly, for an easier review process I've put the different types of changes into different commits (with a description of what the change was)