
On Fri, 24 Apr 2020 07:46:43 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
On Thu, Apr 23, 2020 at 04:24:18PM -0400, Dan Sommers wrote:
On Thu, 23 Apr 2020 14:47:48 -0400 Kyle Lahnakoski <klahnakoski@mozilla.com> 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.
Hold that thought. My point is that aligning them for the sake of aligning them leads to more work in the future, not less.
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.
Fair enough. I'm glad I said something, because Kyle's point was apparently not as clear to me as it was to you.
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".
Given the definition of pymysql.connect and pywhizbangdb.connect, what would I call the name of the user? user_id or user? When I switch back ends, why should I refactor/rename anything? And what happens when I have to support both back ends, rather than simply changing from one to the other once for all time? (I probably should have presented this use case first.)
(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.)
Yeah, they made me use Java at my last paying job, and IMO all such tools do is encourage pointless renaming and huge commits where you can't tell what's been changed vs. what's only been renamed. Sorry, I digress.
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!
We agree that it's not a particularly onerous migration. My point remains that by adopting a style that propagates any particular back end's naming conventions into the rest of your application, any migration is more work than it has to be.
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.
Absolutely, but it seemed to me that Kyle claimed that using the same name throughout an entire application "looks nice," and I pointed out that it does look nice until it makes what should be a tiny change into a larger one. -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan