I came across this the other day in a piece of forgotten code. If you have been in programming for any period of time then you surely have seen it. Its the 'well documented hack' for example:
1
2
3
4
|
//This Item was created per the client
//Instructions to correct a legacy issue
// ...
//Do not delete this method
|
I know people who have written those lines of code, as I am sure that there are some people out there that continue to write lines like this. But I want to take a moment and think about this, is this the type of code that has a place in your product? This is the essence of hacked code. In my current line of work I find code like this alot, programs and methods that have gained so much dust that the people who wrote them are no longer around to ask why they were important. Which brings us to the point of all of this, at what point to you attempt to fix the issues of time that has gone past? How do you turn around a program rifled with code rot, and in the end is it really worth it? Many cases the applications that contain this type of code have millions upon millions of lines of code. The only way to make certain that you don't land yourself in this spot is to always approach code with the thought that someone forty or more years down the line will be reading your code. They will look at your prized application and they will not see the bleeding edge technology that you saw when you designed it. They will see the hulking and aged behemoth that remains, they will look at it with very different eyes. The only gift that you can give to that person is code that is clear, clean, and easy to read. If you see a hack replace it with the corrected code, and don't write any more hackish code. If you are intent on making software your craft, learn it, and exercise it to the best of your ability.