Burying your dead code
eng.grandrounds.com
Burying your dead code
1–10 of 49 posts
Re: Burying your dead code
#2I 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 [1] https://github.com/danmayer/coverband
Re: Burying your dead code
#3Static 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.
Re: Burying your dead code
#4Static 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.
This is my main criticism of the Ruby community. Code that will throw static analysis out is not only accepted, but even welcome.
Python's cold acceptance is already enough to make big projects impractical on it, because every large codebase will gather some undecidable metaprogramming spread through it. But Ruby gets it everywhere.
Re: Burying your dead code
#5Static 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.
This is my main criticism of the Ruby community. Code that will throw static analysis out is not only accepted, but even welcome. Python's cold acceptance is already enough to make big projects impractical on it, because every large codebase will gather some undecidable metaprogramming spread through it. But Ruby gets it everywhere.
[deleted]
Re: Burying your dead code
#6PHPStorm/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.
Re: Burying your dead code
#7Static 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.
This is my main criticism of the Ruby community. Code that will throw static analysis out is not only accepted, but even welcome. Python's cold acceptance is already enough to make big projects impractical on it, because every large codebase will gather some undecidable metaprogramming spread through it. But Ruby gets it everywhere.
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.
Re: Burying your dead code
#8I don't know who to give credit for this concept, but I'm a fan of "tombstoning" functions that are being removed. You basically replace (or prepend) the body of the function with a call to a method that logs the timestamp, calling function, etc.
Here's an example in PHP from a quick google:
https://github.com/scheb/tombstone
I once had to lead a large refactor of a project written in an foreign dynamically typed language and tombstoning was a necessity for how large and poorly designed the projet was.
Re: Burying your dead code
#9I don't know who to give credit for this concept, but I'm a fan of "tombstoning" functions that are being removed. You basically replace (or prepend) the body of the function with a call to a method that logs the timestamp, calling function, etc. Here's an example in PHP from a quick google: https://github.com/scheb/tombstone I once had to lead a large refactor of a project written in an foreign dynamically typed lan…
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.
Re: Burying your dead code
#10I 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, unless your code is all tested via end-to-end tests of features and capabilities, it's _very_ possible that I (or a teammate) wrote some test of our dead helper function, verifying that it handles its edge cases correctly, as a unit test. In that case, we'd still see our code as "covered".
I think we could work around that by making the function deliberately raise an exception, and see which tests break, or commenting out the unit test of that function and see if it's still used. If the code is being exercised in any way other than its own unit tests, it ought to raise an error (or show coverage, depending on tactic). However, this requires us to _already_ suspect that function is dead.