> descriptive names might eventually become non-descriptive
It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing.
This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp R&D, just because something is named DescriptiveThingThatDoesXYZ, doesn't mean it actually does XYZ.
So now they have to verify what a given class or method does every time. Which means you have the same problem that cutesy names cause (the non-trivial effort of looking stuff up) plus the lack of trust that is now engendered in your engineering org.
To be clear, I think I still fall more towards the "use descriptive names" camp. As another commenter has said, by making it easier to add responsibilities to a certain class or service, the "use cute names" camp promotes the creation of God objects that take on too many responsibilities. But man I hate it when a class's name is actively misleading.
I suppose. But even though I've definitely dealt with poorly-named microservices in my career, I can't really say as I've come across many that stuck out to me as being especially misleading, and not to the point where it was really an issue
> if you find that something has drifted to the point of being misleading, then rename it
Sure, this is the proper course of action when that is an option, but...
> it's software not hardware
...if the "software" is a 3rd-party library that external stakeholders are consuming, then it may as well be hardware, because those class and method names represent an API contract that the library's users expect to remain consistent. Which means changing them involves a non-trivial change management and versioning process. Even when the code is internally-facing only, in a large enough codebase it's often the case that multiple teams (and their respective codebases) depend on those names, increasing the complexity of a rename.
> or comment on code reviews that change the functionality to the point where this is a problem
Again, this is the right move if it's available to you. We don't always have that luxury if the names have already gone off-course by the time we first encounter them. Which is often the case an an older codebase that has been written and re-written by many employees who have come and gone over time.
Again, I continue to believe that I'm a member of the "do NOT use cute names" camp. But I'm seeing a lot of cavalierness in these comments about "just rename it, what's the big deal?" and experience tells me that it's not always that easy.
>It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing.
My God... You don't mean to tell me you actually object to having to read code and figuring out what it does in the grand scheme of things?
I swear, everyone wants to be a writer, but no one wants to read and understand.
Not only is your comment needlessly snarky, but it also mis-characterizes what I said. Show me where in my comment I said that I "object to reading code and figuring out what it does in the grand scheme of things".
What I "object to" is not being able to trust that a class or method does what it says on the tin. I don't think that's unreasonable. I'm fine with reading code in order to understand how something works. I don't want to have to read code in order to verify that it does what it promises. See the difference?
You shouldn’t have to read code to understand architecture. But I have had so many conversations like “this is the Auth-service, it also loadbalances and stores a bunch of state, oh and doesn’t do Auth anymore”. Then the name becomes actively harmful to understanding the system.
It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing.
This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp R&D, just because something is named DescriptiveThingThatDoesXYZ, doesn't mean it actually does XYZ.
So now they have to verify what a given class or method does every time. Which means you have the same problem that cutesy names cause (the non-trivial effort of looking stuff up) plus the lack of trust that is now engendered in your engineering org.
To be clear, I think I still fall more towards the "use descriptive names" camp. As another commenter has said, by making it easier to add responsibilities to a certain class or service, the "use cute names" camp promotes the creation of God objects that take on too many responsibilities. But man I hate it when a class's name is actively misleading.