Conversation started Feb 12, 2015 at 15:38.
Feb 12, 2015 15:38
@RubberDuck would it break the code inspections configs if I added a member to CodeInspectionType? I'd like to add LanguageOpportunities and have ObsoleteCallStatementUsageInspection, ObsoleteLetStatementUsageInspection and ObsoleteCommentSyntaxInspection in there, as well as OptionBaseInspection and TypeHintUsageInspection
@Mat'sMug It will not so long as it's not marked with an attribute to be exported.
If it needs to be configurable, then obviously some changes need to be made.
nope - it's just to put them in proper buckets ;)
Worst case, it frak's someone's config file.
and that would make it self-recover right?
Yes. It should.
But it wouldn't even do that.
This is the only relevant Code if you modify the actual CodeInspection class.
private void EnableCodeInspections(Configuration config)
{
    foreach (var inspection in _inspections)
    {
        foreach (var setting in config.UserSettings.CodeInspectionSettings.CodeInspections)
        {
            if (inspection.Name == setting.Name)
            {
                inspection.Severity = setting.Severity;
            }
        }
    }
}
Feb 12, 2015 15:42
cool
I never got around to cleaning these up with an interface due to the reflection.
I still think they should share an interface of some sort though.
The actual inspection would use IInspection in addition to some other interface. Then the reflection could look for that other interface.
IConfigurableInspection?
Maybe.
IConfigurableInspection : IInspection
Well... no.
Feb 12, 2015 15:44
lol
Ignore the terrible name, but it would be more like.
`ICodeInspection : IInspection`
because the *real* inspection does things the configuration type doesn't need to know about.
ah, right
IInspection : IInspectionModel
That ^
 
Conversation ended Feb 12, 2015 at 15:46.