1. 10
  1.  

  2. 4

    Running coverage in production is a bold move.

    I’m not against it per se - I’d love to be able to do it - but I’m not sure it’s a good idea. It adds a moderate amount of performance overhead and a bunch of C code that definitely hasn’t been written with security in mind and is called by literally everything you do. It’s probably fine in practice but it would make me pretty nervous.

    I wonder if something closer to a sampling profiler would more usefully do what they want?

    ETA: I decided this was more usefully a comment on the blog, so I made a lightly edited version of it there.

    1. 3

      https://github.com/SimonKagstrom/kcov might be a less intrusive option, especially as you can attach it to a running process; I’m not sure how well it works for Python, though.

    2. 3

      I’ve always heard “dead code” to refer to commented-out code that is unreachable but still clutters up source files.

      I’m a bit concerned about using coverage tools to remove explicitly-handled edge cases: not only does that mean that if you miss an edge case in your tests, you’re liable to explode in production, but it also means that during code review instincts for “Hey, this looks like it doesn’t handle the most pessimum case” get triggered and cause trouble.

      1. 2

        I think of the case where youre looking at a class that implements a function that isnt called anywhere and clearly was implemented as a utility that isnt quite so useful now but might be later when the class gets more heavily used.