Change is inevitable in software. Workflows change causing necessary changes. This is assuming the software was correct to begin with. Sometimes it isn't. Even the unit tested code! I know. How did we create a unit test and write code over a year ago and we're only now discovering we didn't have the right expectations to begin with.
Well, get over it. Change happens, and sometimes it's because we find bugs.
But when you go in to correct the bug, don't leave...I'm going to call them artifacts in the code. When you're troubleshooting a bug with ThisMethodWillChange(x, y, z), and you find out that y is not necessary because it's actually already figured into x, Clean it up.
Well, get over it. Change happens, and sometimes it's because we find bugs.
But when you go in to correct the bug, don't leave...I'm going to call them artifacts in the code. When you're troubleshooting a bug with ThisMethodWillChange(x, y, z), and you find out that y is not necessary because it's actually already figured into x, Clean it up.
It's helpful to remember that other people have to read this and understand what's important. Especially, if I want to use the method in my code. if I see three parameters in a signature, I'm going to assume they are important, but now I have to go read the comment buried in the method code to find out it's not.
The second method eliminates any confusion that could come from having deprecated parameters in your method signature by removing them from the code. The ideal is to strive to be immediately understood. It's not going to always be the case, but clean code will preserve your credibility as a professional. That way when you do have some complicated logic that must be read deeply to understand it, your colleague will give you the benefit of the doubt instead of the doubt that it's really actually complicated.
