4 ms·
This sounds like a step in a good direction. IMHO diff-based code review creates distorted incentives. Moving large pieces of code around feels harder to revie
by zachrose 9y ago
This sounds like a step in a good direction.
IMHO diff-based code review creates distorted incentives. Moving large pieces of code around feels harder to review, and adding an extra line or two feels easier to review. In the long term, this drives codebases in the wrong direction. (That 900-line method got there through hundreds of innocuous-looking PRs.)
I hope eventually we get tools that make refactorings easy to review. I don't know what that would look like, or how well this can be done in today's languages, but there's room for improvement.
- sdesol 9y agoHaving talked to both Microsoft and GitHub, I get the impression that intelligent code reviews, is an area of great interest for both companies. In the near future (~2 years), I can see us starting to review code in both the traditional way (line diffs) and in a more intelligent way (semantically and by code change impact). For example, if you moved a function 50 lines down and changed a string variable in that function, you'll be able to review and discuss the code changes like so: Semantic changes - Moved function FOO with public scope 50 lines down - Updated string variable FOO with public scope in function FOO Change impact - Moving function FOO 50 lines down does not change its scope. - Lines 56 and 30 in files X and Y in repositories Q and Z, reference the BAR variable. - Open pull request #35, contains FOO function changes as well. - Active releases 1.x and 2.x do not have these changes. The basic idea is, instead of only being able to review and comment on the lines changed, I fully expect us to be able to discuss their impact as well.