On Thu, 23 Apr 2020 14:47:48 -0400 Kyle Lahnakoski firstname.lastname@example.org wrote:
On 2020-04-19 07:23, Richard Damon wrote:
There is also the issue that if we are building a function that might be used with another function, we will have an incentive to name our keyword parameters that there is a reasonable chance would also be passed to that other function with the same keyword name, even if that might not be the most descriptive name.
Many of the function keyword parameters I deal with are data property names; so it makes sense that the data has the same name throughout the codebase. The incentive to align our variable names would be a good thing. Consider pymysql, and the connect parameters
connect( host=host, port=port, user=username, passwd=password )
With the proposal, right, or wrong, there would be an incentive for me to write the caller to use pymysql property names, and the callers of that caller to also use the same property names. This will spread until the application has a standard name for username and password: There is less guessing about the property names. I have done this in ES6 code, and it looks nice.
(We'll assume, for the sake of discussion, that you meant either (a) to use the same name for user and username and for passwd and password, or (2) to use host and port in your explanatory paragraph. IMO, either way, you're disproving your own point.)
Maybe aligning variable names with function keyword parameteres is an anti-pattern, but I have not seen it.
Sure, that works great. Until you decide to change from pymysql to pywhizbangdb, and its connect function looks like this:
connect(uri, user_id, password)
Yes, there will be "layers," or "functional blocks," or whatever your architectural units might be called this week, inside of which it may make sense to have a unified name for certain properties. But the whole application? That sounds like a recipe for future inflexibility.