rubberduck-vba / Rubberduck

Every programmer needs a rubberduck. COM add-in for the VBA & VB6 IDE (VBE).
https://rubberduckvba.com
GNU General Public License v3.0
1.92k stars 302 forks source link

Code Inspection specify project to inspect #2184

Open RaymondWise opened 8 years ago

RaymondWise commented 8 years ago

Code inspection runs on all projects and all modules that are open. It would be nice to be able to either specify the project(s) to inspect, or specify project(s) to ignore.

Related #1520

retailcoder commented 8 years ago

The only way I can see this implemented, is with some drop-down checkbox-list in the Code Inspections toolwindow's toolbar, listing all opened projects; you would un-check projects you want to exclude inspections results for.

As for modules, I think I'd prefer using annotations, e.g. @Ignore RubberduckInspections at the top of a module would have inspections ignore that module.

Thoughts?

ThunderFrame commented 8 years ago

We could maybe create a blacklist of project names, or project paths, like the white-listed trusted locations feature of Office, that would have RD ignore projects that appear on the list. You could also enable/disable inspections by VBE host, in a similar way. That would allow ignored projects to persist between sessions. We'd need to have some form of visual cue that a project was being ignored - maybe as a disabled/greyed-out node in Code Explorer, and a context menu to enable/disable project inspections?

Or, perhaps, we bite the bullet and consider adding a module called something like __Project, and keep a range of meta-data-as-comments in the module?

retailcoder commented 8 years ago

Looks like this can get very complicated, very fast. Makes me wish projects had a .vbp file for this.

RaymondWise commented 8 years ago

I think doing it at the module level would probably be more effort than it's worth considering how often modules rely on other modules.

Right now I can just unload the .xlam that I don't want inspected. I imagine if you had multiple projects open at the same time you could do the same thing, but it would become cumbersome once you have several add-ins going at the same time. One thing about that is I'm not sure how the application handles disabling add-ins (and whether it needs to be restarted for some reason).

Disabling at module level would be nice as sometimes, for instance, I'll write a snippet in a new procedure just to work the bugs out of it before implementing it into the main project. But I think that would be getting a little too nit-picky - next you'd want to inspect only certain procedures and at that point you might as well just be writing your code outside of the VBE.

RaymondWise commented 6 years ago

https://github.com/rubberduck-vba/Rubberduck/issues/3043

retailcoder commented 6 years ago

Another idea would be to add a setting that allows toggling between ActiveProject and Everything for now, and eventually add SelectedProjects and a "session setting" (not persisted) that would include the active project by default. Then a checkbox to determine whether to include projects that would be opened during the session (and toggle the VBE hooks accordingly). This would allow the parser to limit the depth to member level, parsing only the signatures and only creating declarations for the project's public API - a "shallow parse".

As a result, parser performance would improve, memory pressure would be reduced, inspections would have fewer things to look at without explicitly telling them to ignore anything... but they'll still have to actively ignore projects that aren't "deep-parsed", otherwise we'd still end up with results for e.g. unused public members.

Thoughts?

MDoerner commented 6 years ago

Something like this idea is already on the roadmap for integrating the typelib API. Ref #3041.

RaymondWise commented 6 years ago

If you make it a checkbox thing you might have to rework the entire way inspections are started in the UI, otherwise you'd force users to use RD's code explorer.

@MDoerner yeah, I put that link because I think there's quite a few issues all linked to the exact same thing, and can probably be closed. But, I'm not sure how linked the issues really are.