3 ms·
I feel like I might have explained that badly. In my suggestion, the source code would be diffed as a machine-readable AST tree. That means all source code refo
by fxtentacle 5y ago
I feel like I might have explained that badly. In my suggestion, the source code would be diffed as a machine-readable AST tree. That means all source code reformatting actions which do not change the meaning of the source code also do not appear in the diff.
In this explanation about Go:
https://golangdocs.com/golang-ast-package https://golangdocs.com/golang-ast-package
the text following "and we get a nice structure" is what the source code management tools would be working on. It's an abstract representation of the source code's meaning, but not tied to how things are formatted or indented.
- ameliaquining 5y agoI agree it would (maybe) be better if things had been designed this way from the beginning, but as it is it would be totally incompatible with all existing source code management tools, which is a nonstarter. Even if you can switch to a new editor or IDE, you still have to worry about the GitHub web UI and your error reporting tooling and who even knows what else.
- rowanG077 5y agoOn paper I like this idea. But I can't shake the feeling that every non-text based format I have ever encountered sucks.
- davemp 5y ago> That means all source code reformatting actions which do not change the meaning of the source code also do not appear in the diff. The method I described does exactly that. Most modern formatting tools parse code into an AST then rewrite it based formatting rules. So as long as you format both files to the same rules before diffing, only AST changes will show up.