• Jaloopa (unregistered) 
    <?php
//frist comment, linked in all over the place.  not used anymore.
?>
  • Prime Mover (unregistered)

    So ... TRWTF is that Remy can't spell "labyrinth"?

  • Industrial Automation Engineer (unregistered)

    Oh man. Just reading that makes my OCD kick in. *** DELETE *** DELETE *** DELETE ***

  • (nodebb)

    Still potentially an improvement. If that is exactly the content of each of them a quick (all things are relative) program can find those files, then find all references and then remove them...

    [note: I have done almost this exact thing for many a C/C++ project]

  • my name is missing (unregistered)

    At least they avoided the dreaded File Not Found boolean.

  • Robin (unregistered)

    "Let's say you've got an older PHP application"

    Only read this far and I already know its going to be a huge WTF.

    Of course being on this website is also a bit of a clue, but if I come across "old PHP application" anywhere I know I'd run a mile before wanting anything to do with maintaining it...

  • (nodebb)

    Actually, C# offers a worse solution to that. Remove the link to the file from the project (.csproj) file, but keep it in the folder and, of course, in current source control...

  • DFYX (unregistered) in reply to BernieTheBernie

    The current (as in since about the beginning of .NET Core) .csproj format doesn't list files explicitly anymore so that problem is becoming less and less relevant. And even before that, you'd have to manually mess with the project files or work against what your IDE wants to do. When you removed a file from a project, VS would also remove the file. So as long as you don't mess up committing that change, everything should be fine.

    Now what VS does weirdly is removing projects from a solution...

  • Scott (unregistered)

    Not the one from the story. But, reminds me of the idiot consultants I worked with at my last job.

    It's too hard to learn to understand revision history, so let's leave large swaths of code in the file, but commented out. Because we really don't understand the problem we're solving, we might have to go back to the old code. JFC.

  • Scott Simmons (unregistered) in reply to BernieTheBernie

    Thanks, Bernie. You just triggered my PTSD.

  • (nodebb) in reply to DFYX

    The current (as in since about the beginning of .NET Core) .csproj format doesn't list files explicitly anymore so that problem is becoming less and less relevant.

    I detest this idea. The build system should build what I tell it to build, not some random pile of whatever junk is lying around.

  • Hal (unregistered)

    I have always been amazed at the instinct to leave old cruft in projects by some developers. I think its born of "if it aint broke don't fix it" a general rule to which I do subscribe but it is a miss application. Hey let us leave this not even in a library - deprecated method in case something still calls it, or in this case let's leave an empty file laying around because a bunch of other scripts include it...

    The greater risk surely comes from what is being done by the things the developer is implicitly claiming to be unaware, rather then their being broken by removal or changes to whatever. How long could it have really taken to 'grep -rn' the project here and fix all the callers? Vs the time people will spend for the next 10 years running accorss these includes going 'what does that do?" only to go look and find out its an empty file..

  • (nodebb) in reply to Steve_The_Cynic

    You can exclude files, if you need. Instead of listing each file, which is a needless exercise in repetition, it's better to include all the files in the folder and exclude the very few files that shouldn't be built.

  • MaxiTB (unregistered)

    Just two words: Technical debt :-)

    Spoiler: Devs hate it and want to clean it up, line managers hate it and want to ban those words.

  • Jamesbond (unregistered)

    Nice

  • MaxiTB (unregistered) in reply to Steve_The_Cynic

    In C# you can map build actions to extensions, so for example if you have a cs file in the project folder, then it is going to be built and you can also see it in the IDE (Visual Studio).

    However you can overwrite for each file the content type, so for example you can declare it as content and pack it into your artifact as is or you declare it as "none" which means it triggers no build action whatsoever.

    Best practice for all software projects is always to clean up not relevant code (and never comment code out for example). So the removing file from a project means deleting it makes total sense following best practices. And if you need this code for later, well, that's what git is for honestly.

  • Ollie Jones (unregistered)

    Ouch. I resemble this story. "Here, clean up this huge bag of classic asp code" says boss. In our dev and test environments I included lines of code in those vestigial files that would log an error and crash the app, because the inclusion structure was too far out in the stratosphere to completely understand.

    It has to be said, "Remove unused dependencies" is a really wonderful IDE refactoring tool. But that stuff don't work on Classic ASP.

  • Zippy (unregistered)

    At least the cache for those files is nice and zippy.

    "Old file, look at my life. I'm a lot like you were....."

  • (nodebb) in reply to Hal

    How long could it have really taken to 'grep -rn' the project here and fix all the callers? Vs the time people will spend for the next 10 years running accorss these includes going 'what does that do?" only to go look and find out its an empty file..

    You are making the very optimistic assumption, that the developer has access to all code, that potentially depends on that stuff in weirdly broken ways.

  • Prime Mover (unregistered) in reply to Hal

    A workable approach to this problem, if you don't have the resources to hunt down everything which has this sort of dependency-upon-a-nothing, is just to fix them when you run across them. So if you're in a process which invokes an empty file, or calls a do-nothing routine, or has other cruft of this nature hanging around, you just remove it along with making whatever other changes you happen to be doing in that file.

    This approach is generally acceptable if your code changes are micromanaged by a Process. If you're editing a source file anyway, the bean-counters who want to account for every single code change (or more to the point, the peer-reviewers and testers who need to sign off on all source code amendments) will be happier with a change to the effect "while I was in here, I removed some redundant code" than when they see several hundred files all of which need to have an eye cast over them, especially when resource is low. And if you can't make such changes without the Process hauling you over the carpet for making unauthorised changes, then you're looking at polishing your resumé.

  • Prime Mover (unregistered) in reply to Scott

    I once worked in a place where you weren't allowed to delete code, you were required to comment it out, with a comment to the effect of when and why you commented it out, and what specific customer request drove the need for the code change. This was in addition to the fact that you are also maintaining an amendment list at the top of the file.

    A lot of this was fuelled by angry shouting from the customer demanding to know why the functionality had changed, so we needed to be completely bullet-proof concerning the actual changes made when we went back to them reminding them of the change request they'd issued us last week. Happened more often than you'd expect, specially if you have multiple high-level people in the client company who didn't like talking to each other.

  • Hal (unregistered) in reply to Prime Mover

    I have been in some pretty micromanaged places. I can see your approach for decomposing some gwd object or something. I really can't see it for once you are at the point where the object/file/method is finally reduced to a true nothing. That final change set that makes the thing a nothing should include the back out of calls to it.

    As to reviews and what not; the change review should be reviewing the changes, it should not be a big deal for a peer reviewer to sign off on deletion of 'include emptyfilething' even if there are a 100 of them as long as emptyfilething is always exactly that and does not require investigation. If empytfilething still did anything then changes to it have broken all the callers. There is no risk, no 'better approach' to removing those calls. If you can't get team members to sign off on that without reading the entire code base you have no real hope of ever getting any meaningful implementation changes made, you'd never have been able to empty the thing in the first place.

  • (nodebb) in reply to Hal
    Comment held for moderation.
  • (nodebb)

    I have always been amazed at the instinct to leave old cruft in projects by some developers. I think its born of "if it aint broke don't fix it" a general rule to which I do subscribe but it is a miss application.

    It's also commonly a result of too many repetitions of "we've changed our minds about how [x] should work again, can you make it work like it did two months ago except for these three cases?" One of those cases of course requiring wildly different functionality that requires significant changes in the structure of your component, but it doesn't seem much different to the people who are asking for it so they expect you to do it in a week.

Leave a comment on “Old File”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article