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.

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

I think he means that you seem to be speaking for all of the Ruby community (that is, people who write Ruby code). I've personally seen that not all of the Ruby community writes tests, because I've seen Ruby code that doesn't have tests. In fact, I've had coworkers who work with Ruby in multiple jobs in different industries, and in all cases the Ruby application had very few or no tests.

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.

Static analysis is very useful to identify unreachable code given that it can see all the code depending on it.

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.

This is an excellent point, but it should be noted that once you delete the unused API endpoint, finding the rest of the dead code is almost trivial with static analysis.

30-15 to static analysis, I think? ;)