-
Notifications
You must be signed in to change notification settings - Fork 19
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
Address Verification Adjustments #538
Conversation
if code in GOOD_CODES: | ||
r_good = True | ||
break | ||
|
||
if not r_good and r_good_conditional and not r_errors_present: | ||
r_good = True |
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.
This statement reads: if not good ... then say we're good. Is that correct? If so then that's a bit confusing :)
If r_good_conditional
is also set in the if code in GOOD_CODES
, then I think this could be changed too:
if r_good_conditional:
if not r_errors_present:
r_good = True
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.
It's essentially an alternative path to reaching a state of r_good = True
. It could be simplified to just if r_good_conditional and not r_errors_present:
but that has the potential to redundantly set r_good = True
(which doesn't hurt anything, just feels a bit silly). I don't have strong feelings on the stylistic approach, I just wrote it to be abundantly clear that it's a conditional path to reaching a state of r_good = True
since we're treating the code in GOOD_CODES_NO_ERROR
differently than the ones in GOOD_CODES
.
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.
Makes sense. But my worry is looking back at this code a year from now, when something urgent is going on, where it's valuable to minimize the amount of time it takes to understand a conditional. If the concern is a redundant setting on r_good
then that may be expressable as a comment. Sound reasonable?
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.
Definitely, will adjust in a few minutes.
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.
Adjusted and passing Lint now, let me know if there's anything else you'd like me to address before merging. Thanks!
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.
Thanks! I'm +1
Co-authored-by: Daniel McDonald <danielmcdonald@ucsd.edu>
The soft launch revealed some edge cases in both the address verification and address adjustment pieces that needed adjustment, along with supporting pieces that needed improvement: