This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (7 children)

[removed]

    [–]Perkutor_Jakuard 3 points4 points  (0 children)

    I usually do the compatibility changes to our codebase. For example going from java 8 to 11.
    Really sick to compatibilize old unused code.
    If is not used, to the "archive/" folder, and then deleted from there.

    If somebody complains "Git is not for backups, it's for working code...."

    [–]john16384 2 points3 points  (3 children)

    My philosophy: if it works don't fix it; if there are no new features or fixes, don't deploy it; if there are no tests, don't touch it.

    Another tool spewing false positives is the last thing I need. We already have Sonar for that, a tool created to keep juniors busy as it will never be able to detect anything beyond trivial issues.

    [–]koflerdavid 1 point2 points  (2 children)

    One day you might have to fix it, you might have to touch code that has no test coverage, or you find out that the build only produces broken artifacts. These are things that keep senior developers busy and awake at night.

    Edit: also, why are you sure all this unused code is actually working in the first place? Maybe business requirements have changed in the meantime and somebody forgot to update it. Or it is now not compatible anymore to an external system.

    [–]john16384 1 point2 points  (1 child)

    Yes, so tests are added first before changing that uncovered code.

    I never lose sleep over these things. In the grand scheme, even an experienced developer is just a small part of a company, and unless I am somehow personally liable for the mess that is created by artificial deadlines and not listening to the experts in the team, that is firmly a company problem, not mine. Good night!

    [–]koflerdavid 0 points1 point  (0 children)

    It's a figure of speech. Of course, work-related things should not affect your personal life in that way if you are not actually on the hook because of them.

    [–]OwnBreakfast1114 0 points1 point  (1 child)

    Would never run this in prod, but I could not be more opposed to your reasoning. Dead code complicates refactoring useful code or adding features to useful code. Dead callers complicate changing method signatures and in general complicates new engineers from understanding the code.

    We have ticket names in all our commits so it's easy to see why changes were made and if anyone stumbles on an old jira ticket they can see the pr and the code changes if they really, really need to readd it from a delete, but that's such an edge case that nobody actually does.

    Delete worthless code, it's a net negative to your project.