this post was submitted on 17 Jul 2024
73 points (95.1% liked)

Programming

17376 readers
169 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Kissaki 3 points 3 months ago

I strongly and broadly disagree, both with the premise and the argumentation they do.

But first off, and because it's significant to the argumentation; Why is their entire argumentation in line-based diffs, but when I go to their homepage I see screenshots of inline diffs?

Inline-marking of differences are incredibly powerful. Programming language aware diffing should make use of understanding to support the highlighting, with the option to ignore different levels of irrelevance at the users choice.

I don't want anything hidden. I want to default to every difference shown, but put side by side as much as possible, with different levels of highlighting of the differences according to their relevance and significance.

I want to default to every difference shown, but have alternative options to ignore things. I want to have the option to ignore whitespace changes, and potentially additional options to ignore more (this is the opportunity semantic understanding could bring, in addition to the line and change matching).


TortoiseGitMerge allows me to choose between

  • Compare whitespace
  • Ignore whitespace changes
  • Ignore all whitespace changes

I default to the first, but regularly switch to the second and third, when indents change. They are irrelevant when assessing the logical changes. But whitespace is still significant in laying out code. It's both significant, but for different reasons, and as different layers and layers of assessment.

All that being said, we don't use an enforced automatic formatter.

But also, we use whitespace, line breaks, and other syntax consciously. Readability takes precedence over consistency. I hate hard character limits on lines. Sometimes the vertical structure is much more significant to readability than an arbitrary (and often narrow) line character limit.


One example:

Do you write

if (error != null) return error;

or do you write

if (error != null)
    return error;

or do you write

if (error != null)
{
    return error;
}

I dislike the second because its semantic structure not very obvious and somewhat error prone. For simple early returns like this, I prefer the first. But in cases where it's not a simple and short return, the third can be preferable despite being only one statement.

Automated formatters often can't do one or the other alternatively, and sometimes don't allow ignoring one rule.