31–40 of 49 posts
PHPStorm/IntelliJ has this feature where it marks any unused functions as gray. If you want to find where used functions are used, simply hit Ctrl-G and it'll show you all the places.
return new $className();I've run that through many projects over the last year and it's been pretty instrumental in finding the low-hanging stuff easy to pick off.
> 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…
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.
Of course in a dynamic language, or one with reflection, then the distinctions are blurry
There shouldn't be discussion around this topic without mentioning Unused: https://unused.codes I've run that through many projects over the last year and it's been pretty instrumental in finding the low-hanging stuff easy to pick off.
The underlying premise is that, by leveraging ctags and the ability to search for the presence of tokens within a directory, it can estimate what's used based on occurrence frequency and location. Because of this, it's language-agnostic.
Biggest removal I've worked on is ~1500 LOC (a large chunk being JSON); however, I've seen the results from some of our client work at thoughtbot, which have surpassed 3k-4kLOC.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Example: If I have a "dead" add() function with a unit test that asserts add(2,2) == 4, then code coverage would report that function being covered even if no other part of the codebase uses it anymore.
Earlier quoted context omitted.
And so in Ruby, we use test frameworks with advanced mocking, as well as runtime-reflection coverage measurement. Metaprogramming: the cause of, and solution to, all of life's problems.
> And so in Ruby, we use test frameworks with advanced mocking, as well as runtime-reflection coverage measurement. No matter how many times you say it, that doesn't make it true.
Earlier quoted context omitted.
> And so in Ruby, we use test frameworks with advanced mocking, as well as runtime-reflection coverage measurement. No matter how many times you say it, that doesn't make it true.
Care to elaborate?
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?
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.
It doesn't help with potentially reachable but unused cpdepaths, which in my experience make up for the most of 'dead' code.
Think of the functionality in an application that nobody uses or of obsolete API version when all the clients use a more recent version.