Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update expressions.md #104

Closed
wants to merge 1 commit into from
Closed

Update expressions.md #104

wants to merge 1 commit into from

Conversation

pmeredit
Copy link

I think we should enforce the '=>' in match expressions be in a straight column. This makes code much easier to read, and since we will be using an automatic formatting tool, it's not hard to keep up-to-date (the usual argument against such a style). I also think the types in a struct definition should be in a straight column.

I think we should enforce the '=>' in match expressions be in a straight column.  This makes code much easier to read, and since we will be using an automatic formatting tool, it's not hard to keep up-to-date (the usual argument against such a style).  I also think the types in a struct definition should be in a straight column.
@joshtriplett
Copy link
Member

We talked about this specifically, and we have many reasons that we decided not to do this kind of alignment. See #8 for the extensive discussion on that point. But in particular, such alignment often means that a one-line change ripples outwards into other lines, creating noise in diffs and patches that masks the actual change and creates additional conflicts when merging or applying patches.

@pmeredit
Copy link
Author

pmeredit commented Nov 22, 2017

Thanks for the quick response. The diffing issue is a good point. It's unfortunate that git isn't better about that sort of thing (not changing blame over white space, showing patch history without white space differences).

As an alternative, for instance, you could instead apply tooling on the viewing end, such as by having your editor or pager have a "display only" mode that makes it easy to, for instance, toggle such alignment. (You'd never want to use that mode for editing, though.) If we're talking about improving tooling for this case, I think it makes more sense to improve tooling on the display side, keeping the underlying format and representation robust and noise-free.

@joshtriplett
Copy link
Member

@pmeredit There's discussion about that in #8 and elsewhere, as well. To summarize: Working around the problem with tooling doesn't make the problem go away, it just means a subset of tools manage to cope with it. Better not to introduce the problem in the first place.

@pmeredit
Copy link
Author

I agree completely, and I certainly don't want to go about trying to change git. Sorry I didn't see #8 before making the pull request!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants