-
Notifications
You must be signed in to change notification settings - Fork 308
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
format all rust files #421
Conversation
I think it is a good idea to try to settle the formatting issue "once and for all" (even if it leads to conflicts in existing PRs (many of them have conflicts anyway)), as we had some commits that were accidentally introducing quite some formatting changes. Maybe we should just add how we formatted them, or provide a |
I would add a |
should probably squash all the commits in this PR on merge |
I am skeptical: Do we really want to reject pull requests because of (basically) whitespace issues? If so, shouldn't we check as early as possible (e.g. somewhen pre-committish)? Do we know that Is there a bot that applies |
I would say so. No one wants trailing whitespace on the code, nor an inconsistent format style.
rustfmt has some strict stabilization promises, although some limitation apply. Also, this only holds true in versions ≥ 1.0 (but 1.0 is pretty old by now: Nov 19, 2018). There are, however, features we are using in |
I like this idea
thats whats rustfmt.toml does |
TODO: have rustfmt only be run on stable or nightly |
I'm really reluctant for itertools to adopt a viral formatting policy. I would much prefer PR authors adhere to the good practice of submitting minimal patches, than to force everyone to use rustfmt. I don't see evidence that inconsistent formatting is such an issue in the itertools codebase, we need to block PRs on, say, an extra space after the A bot that automatically applies formatting to PRs would be welcome. I'll (reluctantly) merge a mass formatting PR that doesn't change CI. |
This PR started when I was working on #363. As I have autoformat on save, and it formated The only thing here is that its to run a program (cargo fmt). Its not manual labor. I am also willing to rebase current PR-s to make them adhere to master. Also if the style does not adhere the reviewer can easily just add that patch, or just push the changes if the user has put Allow edits from maintainers is enabled. If I was told in a review something like. Hey, the formating check failed. Can you run cargo fmt and then commit that. (it will only change their code if all of the code adheeres to the formating in the first place). Also we might want to make a pre-commit file for those who are useing it. I do not have the knowlage to create fix fmt from a bot. Thow I think this one can be merged (once I fix running fmt on one target) and add that bot in the future |
+1 to applying fmt automatically if possible. I'm new-ish to the rust community, and it's really nice when code-bases are formatted because I can trust that I don't have to worry about style. I can contribute without worrying about formatting, and then just run cargo fmt or have an IDE format the file for me, and it won't introduce a bunch of work for the reviewer. |
I'm going to close this PR, but I promise I'll revisit reformatting itertools in the not-too-distant future. My free time is extremely limited right now (I'm wrapping up my PhD), so when it comes to itertools, my priority is reducing any friction that would keep me from reviewing and merging PRs whenever I can find time. There are two sources of friction here:
So, when I do move forward with this, it will probably be:
In the meantime, the implications for would-be contributors are:
|
No description provided.