This question already has an answer here:
For this case let's assume something like... "removedNonPriceChangingConfermations" that is in no way relating to things that happened in the past tense, nor does it return a list of removed items (which you would never need in this context).
If you can't spot the other thing wrong with it, I challenge you to a high-stakes spelling contest.
Is it better to rename the method to more accurately and less painfully describe what it actually does?
Or given that it sits within a 20-class roller coaster of fail (mapping a db queried table to a bean) is it better to leave it as a sort of a warning buoy of the unique minds that crafted the code with comments to explain what it really does at the definition? At least until we can properly refactor the silly thing.
If relevant, assume a high turnover rate but always good intentions.
Please Note: It's not hard to change the method name. This question is more generally about whether it isn't better to leave a really dumb method name intact so people can see that they're walking into "one of those parts" of the code base or if I should in fact change it to better reflect what it actually does.