On 4/19/20 11:28 AM, David Mertz wrote:
On Sun, Apr 19, 2020, 7:24 AM Richard Damon <Richard@damon-family.org mailto:Richard@damon-family.org> wrote:
One of the key motivations of this proposal is to make nicer a call with a lot of key word arguments where the local variable name happens (intentionally) to match the keyword parameter name.
I think Stephen said that this "same name across scopes" is an anti-pattern. I mostly disagree, though obviously agree that it varies between different code. He mentioned something like:
And that would be better with email_john and email_jane as names in outer scope.
I've worked with large code bases where the equivalent complex object is used in many places. Not necessarily as a continuous life of an actual object, but sometimes sent as JSON, other times read from database, other times calculated dynamically, etc.
For example, maybe there is a 'person_record' that has as attributes/keys/whatever name and email. But in this existing code, a different name is used through a call chain and in different corners of the code. E.g. we read json_record, which calls something naming it dynamic_record, which eventually arrives at a function that saves db_record. But these are all actually the same object layout or even the same object.
When it comes time to refactor—now we need to rename 'telephone' as 'home_phone' and add 'cell_phone'—finding all the locations to change is a PITA. If only we could grep 'person_record' globally, it would have been easy.
As with most anti-patterns, there tend to be cases where they actually help (which is why some think of them as a useful pattern), but then it get applied beyond the cases where it is actually useful, and then becomes the anti-pattern.
My personal thought on the case you are presenting, is that I would be tempted to grep for telephone, to change that because the change likely affects not just this given structure, but may also impact related structures which also assumed a single phone number.