What should semantic diffs highlight: The change or its effect?
-
If the formatting configuration forces one specific style then that is the deliberate choice; to have that one.
If there is no uniform single string quoting it is useful to differentiate between them; for example if for normal strings
'is preferred while for specific cases where escaping characters like\nis required,"must be used. -
would make it clearer
Would make what clearer?
If I change a string to a raw string or an interpolated string, it is a semantic change on the entire string, even if it leads to consequential changes only on subsections of it.
-
-
it allows string interpolation with the syntax in the photo
-
The most obvious option: highlight what changed, the whole string. If you changed the string from interpolated to non-interpolated, the meaning of the whole sring changed; it is no longer a method to concatenate variables, it has become a literal string.
Same for the example of single to double quotes. In some languages, double quotes are only used in specific contexts, so its use changes the meaning of the code.
-
Options 1 and 3 make sense to me.
Option 2 feels like something specific:
Similar to cases like100vs100Uwith the second one denoting "unsigned". -
I like the way azure dev-ops do it, they highlight the entire line with a soft color and the changes with a harder one. Isn't not semantic afaik.
-
The post chooses to use Python, where single and double quotes are equivalent and are not a semantic change. In other languages that might be, but that's not the point of the article. A semantic diff is language dependent.
-
Just because they are equivalent for the labguage does not mean they are interchangeable. I may choose to use single or double quotes in specific cases and need that change to be visible, even if the language rules say it is indifferent.
This is the obvious one: The way the string is written changes, but its content remains the same. There is nothing to highlight for SemanticDiff.
Moreover, my point was about how they phrase it. It seems they dismiss what the code means to developer by mentioning "content" and discarding "the way the string is written".
-
I may choose to use single or double quotes in specific cases and need that change to be visible, even if the language rules say it is indifferent
Then a semantic diff is not for you, just use the old method.
-
just stick a verification task in ci. if I have to check if the format matches the standard in a code review instead of reviewing meaningful things my time is being wasted
-
that's not a one letter template literal, that's built in python syntax. it only has combinations of u r and f and no user defined option. f makes it templated
-
this is neat but also is a closed source extension. I use https://github.com/Wilfred/difftastic which doesn't do quite as much and doesn't integrate outside of git's diff, but is still significantly better than nothing
-
Yeah exactly, I'm not it was clear that it was what I meant by "the formatter should ensure ..."
