Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving all default settings to .settings file #3718

Merged
merged 17 commits into from
Feb 8, 2018

Conversation

rkapka
Copy link
Contributor

@rkapka rkapka commented Jan 21, 2018

Closes #3555

@rkapka rkapka added the PR-Status: Review Requested No more commits, PR is ready for the eyes that need to see it. label Jan 21, 2018
@retailcoder
Copy link
Member

Just to be clear: this PR is moving all default settings values to the .settings file, correct?

@rkapka
Copy link
Contributor Author

rkapka commented Jan 22, 2018

@retailcoder Yes 😀. I will edit the title.

@rkapka rkapka changed the title Moving all settings to .settings file Moving all default settings to .settings file Jan 22, 2018
@rkapka rkapka mentioned this pull request Jan 23, 2018
# Conflicts:
#	RubberduckTests/RubberduckTests.csproj
@retailcoder
Copy link
Member

retailcoder commented Jan 24, 2018

AppVeyor is claiming a build error here, involving ParseTreeInspectionBase and DefTypeInspection

@rkapka
Copy link
Contributor Author

rkapka commented Jan 24, 2018

Yeah, I didn't take a closer look that an inspection was added. The default severity is now inside the .settings file, so there is no constructor in ParseTreeInspectionBase taking a severity.

@rkapka
Copy link
Contributor Author

rkapka commented Jan 24, 2018

I just noticed that I also moved the InspectionType into the .settings file, so at the moment it's specified there and in a property. Maybe the property could be defaulted to some value in the base class and be read from only if the inspection isn't present in the .settings file...

@retailcoder
Copy link
Member

@rkapka but an inspection's InspectionType isn't a setting.. hmm, do we want them there though? Having inspection types in the settings makes it easier to visualize the groupings and distribution... I'm all for it! 👍

return TodoExplorerVisibleOnStartup;
}
//Oh. Hello. I have no clue who you are...
return false;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

_defaultSettings = new DefaultSettings<CodeInspectionSettings>().Default;

var nonDefaultInspections = foundInspections
.Where(inspection => !_defaultSettings.CodeInspections.Select(x => x.Name).Contains(inspection.Name));
Copy link
Member

@retailcoder retailcoder Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's iterating the inspection settings twice. .Any() could help here I think:

var nonDefaultInspections = foundInspections
    .Where(inspection => !_defaultSettings.CodeInspections.Any(x => x.Name == inspection.Name));

Copy link
Contributor Author

@rkapka rkapka Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any also iterates, so I will extract the names to a HashSet to avoid this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, but Select is first projecting all elements into an IEnumerable<string>, which Contains then iterates. Any skips the projection part; HashSet seems overkill.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part got removed.

}

public override int GetHashCode()
{
unchecked
{
var hashCode = Name?.GetHashCode() ?? 0;
hashCode = (hashCode * 397) ^ (int)Severity;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Holy crap, nice catch!! 😲

Copy link
Member

@retailcoder retailcoder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The amount of cleanup is impressive, some serious issues are fixed too, very good PR! I have a concern about the InspectionType though - see comments. I think this PR is the pefect opportunity to clear this up. Thanks!

@Vogel612
Copy link
Member

While InspectionTypes should not be a user-configurable setting, I think it's not a generally bad decision to make such settings configurable through our app settings.

This should also remove the tests on all the inspections that check for a certain InspectionType...
OTOH, this means that any plugged in inspections need to be configurable through this general app-configuration, which is not quite there yet.
Then again we're not really ready for any plugins quite yet...

AFAIK we do not overwrite the Inspection's InspectionType with values read from settings, so in itself it's not used and should be removed...

@retailcoder
Copy link
Member

@Vogel612 the InspectionType isn't read from settings, but the inspection settings UI does use that property for grouping the inspections, so it can't just be removed from the model.

Ideally the config file would drive what the InspectionType is for each inspection, but then individual inspections would have some way of specifying an InspectionType if we don't have a default for it... but then, this makes a rather confusing API: when implementing a new inspection, you immediately pick up that you need to provide an InspectionType, but not that you need to have it in the .settings file.... catch-22?

@rkapka
Copy link
Contributor Author

rkapka commented Jan 25, 2018

@retailcoder How about making InspectionType a non-abstract, get/set property and defaulting it to QualityIssues or whichever value is most reasonable? CodeInspectionConfigProvider will set the property in its constructor using default settings. That way it would behave similarly to Severity.

@retailcoder
Copy link
Member

@rkapka that can work... We just don't want the inspection types to end up in the serialized xml config file.

@Vogel612
Copy link
Member

This will need to incorporate the new settings for #3717

@rkapka rkapka removed the PR-Status: Review Requested No more commits, PR is ready for the eyes that need to see it. label Jan 31, 2018
@rkapka rkapka added the PR-Status: WIP Pull request is work-in-progress, more commits should be expected. label Jan 31, 2018
@rkapka
Copy link
Contributor Author

rkapka commented Feb 4, 2018

That would be all except leaving the inspection type setting out of the user-specific settings file. Excluding the property from serialization will prevent the .settings file from including the value in the default settings. I don't know how to solve this at the moment... It is possible to write a custom type converter and use SettingsSerializeAs.String to store a string representation of the setting in the .settings file, including the inspection type. But I am not sure how to embed such a string inside the XML setting for CodeInspectionSettings and if it is possible to serialize individual inspections as strings in the .settings file and as XML in the user-specific file.

For now the inspection type is visible in the user file, but it is ignored by the configuration provider. Any comments/ideas?

@Vogel612
Copy link
Member

Vogel612 commented Feb 6, 2018

Also fixes #2240

@rkapka rkapka added the PR-Status: Review Requested No more commits, PR is ready for the eyes that need to see it. label Feb 7, 2018
@retailcoder retailcoder removed the PR-Status: WIP Pull request is work-in-progress, more commits should be expected. label Feb 8, 2018
@retailcoder
Copy link
Member

For now the inspection type is visible in the user file, but it is ignored by the configuration provider. Any comments/ideas?

I think that's more than good enough... the configuration file is intended to be accessed from the settings dialog.. I guess we can consider it by-design.

@retailcoder retailcoder merged commit 8c57bed into rubberduck-vba:next Feb 8, 2018
Copy link
Member

@retailcoder retailcoder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for this 👍

@rkapka rkapka removed PR-Status: Review Requested No more commits, PR is ready for the eyes that need to see it. discussion labels Feb 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants