Introduce semantic parsing in Line Impact calculation

This is already done to some extent, but here are a few ways in which interpreting code semantically could improve the approximation of dev cognitive effort. This list showcases examples of when making a specific change to the code *requires* another follow-up change. Usually, the follow-up change is complementary, but does not act in any way to evolve the codebase (not more than the initial change did).

1. Adding another potential type to an object (should get all Line Impact) vs adding an "else" branch in the section of the code verifying that type
2. Acquiring a synchronization-type object vs releasing it
3. More generally, any resources that need symmetric operations, such as allocating memory in C
4. Extending the db schema of an object to house another column (vs adding that new property to trivial API/method calls on other layers of the app)
5. Creating a new type of Error object/event vs "catching" it in all invocations of the error-triggering code

Not planned Suggested by: Lucian Upvoted: 14 Dec, '21 Comments: 1

Comments: 1

Add a comment

0 / 1,000

* Your name will be publicly visible

* Your email will be visible only to moderators