Closed dracodoc closed 7 years ago
It sounds like you're looking for something more like a linting system, i.e. lintr
Yes it will be similar to that, but checking different issues. I found the most checks in lintr
are not really useful for me (a lot of them are formatting issues will not happen for me).
I knew this usage probably didn't follow the original strict philosophy, but after changed one place in strict_abort
from abort(msg)
to warn(msg)
, I can run my Shiny app with strict
now and see all the issues in one run. There are some duplicates can be filtered out, but it's still much easier for me. Otherwise I need to fix every issue in order to see next issue.
> shiny::runApp('shiny/app')
Loading required package: shiny
Loading required package: pacman
Listening on http://127.0.0.1:4858
Warning: [strict]
Multiple definitions found for `box`.
Please pick one:
* shinydashboard::box
* graphics::box
Warning: [strict]
Multiple definitions found for `box`.
Please pick one:
* shinydashboard::box
* graphics::box
Warning: [strict]
Multiple definitions found for `source`.
Please pick one:
* XML::source
* base::source
If the strict checks can be run as inspections instead of fail on error, there will be these advantages:
%>%
.strict
check are not equal. Some definitely should be fixed, some are less serious. An inspection that report all the problems will allow user to apply some priority on them.I understand to run these conditions check as inspections probably is not easy, and could need substantial changes from current code.