4 ms·

> 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 th

> 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 definitively if a block of code is dead?

choward 9y ago
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 9y ago
  [deleted]
- reificator 9y ago
  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.
khedoros1 9y ago
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".
- reificator 9y ago
  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.
  - khedoros1 9y ago
    "Pretty sure" stinks, if you're coming from a world where the compiler can tell you "this code never gets called by anything".
    - reificator 9y ago
      When you're making a library, the compiler can't do anything of the sort.
adrianN 9y ago
Finding all dead code would mean solving the halting problem, even in the simplified case when you're not writing a library whose consumers may no longer use an exposed function.
- pacaro 9y ago
  Now we're discussing the meaning of "dead code". I'm pretty certain that the OP was referring to methods that have no callsites. That doesn't require much in the way of proof, the git bisect seems to be more about identifying when it became dead. Now if you have methods that have existing callsites, but aren't being called, then yes, you may need to solve the halting problem to prove that no basis path that is actually followed calls the code in question. Of course in a dynamic language, or one with reflection, then the distinctions are blurry

choward 9y ago

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 9y ago
[deleted]
reificator 9y ago
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.

khedoros1 9y ago

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".

reificator 9y ago
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.
- khedoros1 9y ago
  "Pretty sure" stinks, if you're coming from a world where the compiler can tell you "this code never gets called by anything".
  - reificator 9y ago
    When you're making a library, the compiler can't do anything of the sort.

adrianN 9y ago

Finding all dead code would mean solving the halting problem, even in the simplified case when you're not writing a library whose consumers may no longer use an exposed function.

pacaro 9y ago
Now we're discussing the meaning of "dead code". I'm pretty certain that the OP was referring to methods that have no callsites. That doesn't require much in the way of proof, the git bisect seems to be more about identifying when it became dead. Now if you have methods that have existing callsites, but aren't being called, then yes, you may need to solve the halting problem to prove that no basis path that is actually followed calls the code in question. Of course in a dynamic language, or one with reflection, then the distinctions are blurry