mkr-plse

Can you elaborate further? It will be interesting to see other use cases for code cleanup.

Do you already know the code that is not executed? If not, dynamic program analyses can help with identify the regions of code that are untouched (e.g., take a look at javaagent for Java programs). Subsequently, you can use some form of reachability analysis to determine which code blocks to delete without causing a compilation failure.

For Piranha: a) Code related to stale flags is deleted b) Determination of staleness is based on status of the feature. c) Patch is created automatically and in a majority of the cases, compiles and passes tests.

Based on my understanding of unused codes, a) unused codes is used to delete deadcode independent of features b) determining the deadcode is based on their usage in tests c) unclear whether the code is flagged for deletion or a patch created.

Piranha author here -- Will you be willing to contribute it to Piranha?

Interesting. We don't have tooling for this yet but extending the Piranha static analysis may help detect the issue.

The flag management system has information on activity pertaining to various flags. After prolonged inactivity, a flag is considered stale and a diff is generated. This is a heuristic (in the absence of expiry date for a flag) and the final decision on cleanup is made by the flag owner.

BTW, we also have a tech publication at https://github.com/uber/piranha/blob/master/report.pdf where we discuss some of the design tradeoffs pertaining to the stale flag cleanup problem.

Can you elaborate on what you mean by conflict detection? Are you trying to understand how flags are dependent on each other?

Manual code review and CI only. In our experience of deleting more than 2.5K flags, testing would have helped in one case but then the code was not tested well when the flag was introduced.