Skip to content

Make the fuzzy searching flexible by passing in the fuzzy matcher - #18270

Merged
Dongbo Wang (daxian-dbw) merged 7 commits into
PowerShell:masterfrom
daxian-dbw:fuzzy
Oct 17, 2022
Merged

Make the fuzzy searching flexible by passing in the fuzzy matcher#18270
Dongbo Wang (daxian-dbw) merged 7 commits into
PowerShell:masterfrom
daxian-dbw:fuzzy

Conversation

@daxian-dbw

@daxian-dbw Dongbo Wang (daxian-dbw) commented Oct 13, 2022

Copy link
Copy Markdown
Member

PR Summary

Make the fuzzy searching flexible by passing in the fuzzy matcher instead of using the SearchResolutionOptions.

PR Checklist

@daxian-dbw
Dongbo Wang (daxian-dbw) marked this pull request as ready for review October 13, 2022 21:15
@daxian-dbw Dongbo Wang (daxian-dbw) added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Oct 13, 2022
public const int MinimumDistance = 5;
internal readonly uint MinimumDistance;

internal FuzzyMatcher(uint minimumDistance = 5)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Given that we now expose setting the min distance in the cmdlet, I wonder if we should change this to 3 instead of 5 to get more reasonable results and likely a bucket 3 breaking change

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

It turns out we don't need to declare a default value for this parameter.
The -FuzzyMinimumDistance in Get-Command is 5 by default, are you suggesting changing it to 3? I think it makes sense, and will make the change.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I changed the default min distance back to 5 because the change caused a test to fail -- pwsh.exe is expected to return for pwsw on Windows by default. I guess we need to improve the fuzzy matcher somehow, to ignore the .exe extension
on the to-be-compared string when the reference string doesn't have .exe.

@SteveL-MSFT Steve Lee (SteveL-MSFT) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM, just one question to consider

@pull-request-quantifier-deprecated

Copy link
Copy Markdown

This PR has 122 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Medium
Size       : +63 -59
Percentile : 44.4%

Total files changed: 5

Change summary by file extension:
.cs : +63 -59

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@daxian-dbw
Dongbo Wang (daxian-dbw) merged commit bc1f369 into PowerShell:master Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log Medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants