Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Burying your dead code

eng.grandrounds.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Burying your dead code

#21

Post by chris_wot »

gknoy wrote: post #10
boffinism wrote: post #2

I may be being stupid here, but shouldn't you really be using a comprehensive test suite and a code coverage tool like simplecov [0] to automatically show you your dead code? Or if you don't do test coverage (!) something like coverband [1] in production? That way you get to see straight away which code is genuinely dead rather than having to go spelunking with `git-bisect`? [0] https://github.com/colszowka/simplecov…

I don't think it would work as well as we'd hope. Our projects aim for ever-increasing code coverage; it seems silly, esp as we get closer to 100%, but it seems to be pertinent here. If I were to refactor some function to no longer be used, one would hope/expect that code coverage for that function would be missing, and thus we'd realize (or at least be able to notice more easily) that it was dead code. However, unle…

If there was sufficient code coverage then the test would hopefully invoke a function that eventually calls on your potentially dead function.

Re: Burying your dead code

#22

Post by cl0wnshoes »

Neat idea, might look into this for .NET, the obsolete attribute doesn't really cut it currently. Some of the comments on here mention unit test, static analysis, and just a good all round IDE makes this a non issue, but those are the scenarios I find most dangerous.

A unit test does not prove without a doubt a class/method are not in use. Static analysis/good IDEs are bound to the immediate code base, they can't determine usage when your code is shared across multiple workspaces or when the class/method are only called externally.

Tombstoning isn't perfect, but its safer than what I typically do given a sufficient amount of time to collect logs along side a bit of analysis on a case by case basis (e.g. method AddTwoNumbers() not being called for 6 months maybe okay to remove, whereas EndOfYearReportGenerator() not being called for 6 months shouldn't blindly be removed.)

Re: Burying your dead code

#23

Post by chris_wot »

bradmwalker wrote: post #14
thehoagie wrote: post #13

Git bisect also has a test command where you can automate grepping for usage. You can use something like wc to determine whether you matched one or more than one result. This automates the bisect and let's you take a nice break from the computer while it does it's magic.

Git log -p -S

If you use a regex then try:

  git log -p -G regex

Re: Burying your dead code

#24

Post by cl0wnshoes »

tdriggs wrote: post #3

Static analysis is your friend here. TypeScript, Rust, and C# can all identify dead code and report errors or warnings from that, and can perform "find all usage" searches across a workspace.

If your code base is only used within a single workspace (and you know this with certainty) then I completely agree. The issue arises when your code is used outside of your workspace as a shared code base or a public facing API.

Re: Burying your dead code

#25

Post by falcolas »

dhimes wrote: post #17
dpcx wrote: post #9

Earlier quoted context omitted.

I've used tombstoning as well. The biggest problem is that you have to let it run long enough to determine if anyone is actually using that method - and with sections of an application that are not oft-used, you could be waiting a very long time to find out.

Wouldn't a test suite help with that?

Well, that depends. If you have 100% coverage, you don't have dead code. But just because code is tested doesn't mean that it's actually in use outside of the test suite.

There's lots of ways that code could become dead, even if it's still accessible via a test suite.

Re: Burying your dead code

#26

Post by falcolas »

boffinism wrote: post #2

I may be being stupid here, but shouldn't you really be using a comprehensive test suite and a code coverage tool like simplecov [0] to automatically show you your dead code? Or if you don't do test coverage (!) something like coverband [1] in production? That way you get to see straight away which code is genuinely dead rather than having to go spelunking with `git-bisect`? [0] https://github.com/colszowka/simplecov…

100% coverage in testing doesn't indicate 100% usage in production. For example - if an API endpoint is no longer in use (say, it's a v1, and your company has now entirely moved to v4), the code in question will still be covered by testing - it's not dead according to the test suite.

Re: Burying your dead code

#27

Post by tcopeland »

falcolas wrote: post #26
boffinism wrote: post #2

I may be being stupid here, but shouldn't you really be using a comprehensive test suite and a code coverage tool like simplecov [0] to automatically show you your dead code? Or if you don't do test coverage (!) something like coverband [1] in production? That way you get to see straight away which code is genuinely dead rather than having to go spelunking with `git-bisect`? [0] https://github.com/colszowka/simplecov…

100% coverage in testing doesn't indicate 100% usage in production. For example - if an API endpoint is no longer in use (say, it's a v1, and your company has now entirely moved to v4), the code in question will still be covered by testing - it's not dead according to the test suite.

Yup but coverband doesn't do code coverage during tests (like simplecov); it does code coverage in production by sampling requests and profiling them.

Re: Burying your dead code

#28

Post by [deleted] »

choward wrote: post #12
saosebastiao wrote: post #11

> Removing dead code from your codebase is a simple process at its core: find the dead parts, prove that they’re dead, and delete them. The tricky part is in that second step, but after a little trial and error, we discovered a couple tricks to speed up the process. The tricky part shouldn't be the second step. The second step shouldn't even exist. How is it that in this day and age, your compiler can't tell you defi…

You can prove that code is referred to by other code in the same project. However, you can't prove if your exposed API is being used. For example, let's say you have an HTTP API endpoint and you're not sure if your front end is using it.

[deleted]

Re: Burying your dead code

#29

Post by reificator »

choward wrote: post #12
saosebastiao wrote: post #11

> Removing dead code from your codebase is a simple process at its core: find the dead parts, prove that they’re dead, and delete them. The tricky part is in that second step, but after a little trial and error, we discovered a couple tricks to speed up the process. The tricky part shouldn't be the second step. The second step shouldn't even exist. How is it that in this day and age, your compiler can't tell you defi…

You can prove that code is referred to by other code in the same project. However, you can't prove if your exposed API is being used. For example, let's say you have an HTTP API endpoint and you're not sure if your front end is using it.

Then my first step would be to check the logs, or start logging if there are none currently.

You get a nice structured logging format set up, log every request, and feed that into something you can graph and query. Leave that on long enough (long enough being a length of time that depends on what the endpoint does and how critical it is, as well as how much traffic you see regularly) and you can figure out what's being used pretty quickly.

Re: Burying your dead code

#30

Post by reificator »

khedoros1 wrote: post #16
saosebastiao wrote: post #11

> Removing dead code from your codebase is a simple process at its core: find the dead parts, prove that they’re dead, and delete them. The tricky part is in that second step, but after a little trial and error, we discovered a couple tricks to speed up the process. The tricky part shouldn't be the second step. The second step shouldn't even exist. How is it that in this day and age, your compiler can't tell you defi…

Reading through the discussion here: most of the comments are assuming interpreted languages. The article itself was talking about Ruby. And I'd imagine that in any form of client-server system, especially if there are multiple client implementations, it would be hard to tell if specific server endpoints are definitively "dead".

If you don't see any logged requests to that endpoint for a certain period of time, you can be pretty sure of its status.

If you don't have that detail in your logs, that's step 0.

Post reply on HN