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
[MAINTENANCE] Renaming Metric Name Suffixes using Enum Values for Better Code Readability #6575
Conversation
✅ Deploy Preview for niobium-lead-7998 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
👇 Click on the image for a new way to code review
Legend |
…45/alexsherstinsky/batch_metric_store/metrics/execution_engine/standardize_metric_names_using_proper_enum_values-2022_12_13-277
69f9552
to
36df2fe
Compare
…45/alexsherstinsky/batch_metric_store/metrics/execution_engine/standardize_metric_names_using_proper_enum_values-2022_12_13-277
c4f907b
to
1111d3e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
…erstinsky/batch_metric_store/metrics/execution_engine/standardize_metric_names_using_proper_enum_values-2022_12_13-277
Scope
The
Metrics
layer utilizes a naming scheme that corresponds toMap
metrics,Condition
metrics,Aggregate
metrics, and others. These are properly delineated byEnum
values with corresponding suffixes inExecutionEngine
module. However, in otherMetrics
modules, strings are used to designateMetric
function types, which makes reading this already highly complex code even more difficult, unnecessarily. This effort improves the readability by using enums and meaningful variable names consistently.Please annotate your PR title to describe what the PR does, then give a brief bulleted description of your PR below. PR titles should begin with [BUGFIX], [FEATURE], [DOCS], or [MAINTENANCE]. If a new feature introduces breaking changes for the Great Expectations API or configuration files, please also add [BREAKING]. You can read about the tags in our contributor checklist.
Changes proposed in this pull request:
After submitting your PR, CI checks will run and @cla-bot will check for your CLA signature.
For a PR with nontrivial changes, we review with both design-centric and code-centric lenses.
In a design review, we aim to ensure that the PR is consistent with our relationship to the open source community, with our software architecture and abstractions, and with our users' needs and expectations. That review often starts well before a PR, for example in github issues or slack, so please link to relevant conversations in notes below to help reviewers understand and approve your PR more quickly (e.g.
closes #123
).Previous Design Review notes:
Definition of Done
Please delete options that are not relevant.
Thank you for submitting!