On Thu, Apr 23, 2020 at 04:24:18PM -0400, Dan Sommers wrote:
On Thu, 23 Apr 2020 14:47:48 -0400 Kyle Lahnakoski firstname.lastname@example.org wrote:
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.)
Kyle is explicitly discussing how this proposal will encourage names to be aligned in the future, where today they are pointlessly using synonyms. The point is that user/username and passwd/password are not currently aligned, but this proposal will encourage them to become so.
So, no, you should not be assuming that Kyle made a mistake with those two pairs of names, as that would defeat the purpose of his comment.
As for your second point, host and port are already aligned. How does the existance of aligned names today disprove the point that unaligned names will, in the future, become aligned?
Kyle: "Yesterday I ate lunch. Tomorrow I intend to eat lunch."
You: "You ate lunch yesterday? That disproves your claim that you will eat lunch tomorrow."
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:
This counter-point would be more credible if pywhizbangdb actually existed, but okay, let's assume it exists.
connect(uri, user_id, password)
Sounds to me that this is actually a point in favour of aligning variables. Then changing to pywhizbangdb would be a relatively simple "change variable name" refactoring for "username" to "user_id".
(There are refactoring tools in IDEs such as PyCharm that will do this for you, rather than needing to do a search and replace yourself. But I haven't used them and I cannot tell you how good they are.)
Whereas the change from host+port to uri is a more difficult (in the relative sense, not in any absolute sense) two line change:
* use host and port to generate a new variable `uri` * change the call to connect to use `uri` instead of host + port.
Either way, this doesn't seem like a particularly onerous migration to me. If only all migrations of the backend were that simple!
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.
Fortunately, this proposal doesn't make it mandatory for people to use the same variable name throughout their entire application, and the function call syntax `func(somename=anothername)` will remain valid.