Remove line from crc32 to be able to track functions in changed files

[wprigollopes]

tombstone/src/core/Model/Tombstone.php

Line 67 in 1560e40

return crc32($this->file->getReferencePath()."\n".$this->line."\n".$this->functionName."\n".implode(',', $this->arguments));

When we save the logger, we use the tombstone hash to save the file log. As we are using the current line call, if we modify the file for any purpose, the line could change so, when we run a new tombstone-analyzer routine we will have one deleted tombstone call and a new one dead call.

So, for this situation, can we consider removing the line from the tombstone hash?

[scheb]

As we are using the current line call, if we modify the file for any purpose, the line could change so, when we run a new tombstone-analyzer routine we will have one deleted tombstone call and a new one dead call.

That's actually not true. The hash value is only used to deduplicate repeating calls from the same tombstone. That doesn't change anything about weather a tombstone is dead, undead or deleted.

Matching logged tombstone calls to tombstones in the codebase is based on two strategies:

• Location of the tombstone (file + line + inscription)
• Context of the tombstone (surrounding method/function + inscription)

If one of those matches, the logged call is assigned to the tombstone. So you can move a tombstone around, as long as one of those criteria stays the same the analyzer would still be able to match it.

Though, if you heavily refactor your codebase (change method names and change code to shift tombstones around), then it can in fact happen, that previously logged tombstone calls are no longer be matched to that tombstone in the code. In that case, the previously logged tombstone calls would show up as deleted and you'd get new tombstones showing up in the report. Once that code is executed and new tombstone calls are being sampled, you should quickly get a refreshed clear picture, which ones are dead and which ones aren't. But for that you have to give the system some time to collect new samples after a heavy refactoring.

If this way of matching is not good or stable enough for you, the idea for custom matching strategies is here, but it hasn't gained much interest yet.

[wprigollopes]

Those two matches look like a good strategy. The only number that could be not exact is the deleted but just in extreme cases. Also, I'm considering that the analyzer needs to be run periodically to have a good summary of the evolution of dead code results and to maintain effective statistics of the code.

Thanks for the clarification.