4 ms·

> It's worse than being non-descriptive- it's that they become misleading. if you find that something has drifted to the point of being misleading, then rename

• toomanyrichies 4y ago
  > 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.