Giters

rust-ndarray / ndarray

ndarray: an N-dimensional array with array views, multidimensional slicing, and efficient operations

Home Page:https://docs.rs/ndarray/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Code formatting

nilgoyette opened this issue · comments

commented

The code in this repository doesn't seem to be formatted by rustfmt, which can lead to useless discussions and back and forth in the PRs. The advantages of a standard code formatter are already well known. As a programmer myself, I don't see any reason not to use it, but I'm might have a blind spot.

A comment from @adamreichold

The two options I see personally is to make a single mass change to enforce Rustfmt usage throughout the code base including in the CI. Or to limit this to files touch in any PR. (I think it should be possible to enforce this using GitHub Actions' path rules.)

((Personally, I would be very much in favour of Rustfmt usage throughout. I don't care much about the formatting itself as long as it is uniform and automatic. But that just is not the approach taken by this code base so far which I think could override this perspective.))

@adamreichold I understand that doing a PR with a full code formatting commit would

  • make "git blame" useless
  • create conflicts in all PR

Would the use of "GitHub Actions' path rules" solve those 2 problems?

commented

Would the use of "GitHub Actions' path rules" solve those 2 problems?

Only insofar it would smear the change out over many PR, but once a file has been touched by a PR and hence formatted, the effects w.r.t. "git blame" or conflicts would the same for this file. The path rules only enable running "rustfmt --check" on the files touched by PR only, instead of running cargo fmt --check wholesale.

commented

To contribute to fact-finding: rustfmt ruins visual layout of some "array![] literals" in the code.

I don't mind formatting the this whole repo. I explicitly want to stop me and my opinions blocking progress here and everywhere, so I just think go for it if most maintainers agree. Coordinate with big in progress PRs if any and merge reformat before/after them.

commented

make "git blame" useless

See https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view.

Only insofar it would smear the change out over many PR

With the above in mind, having a single commit to ignore would be easiest.