Skip to content

Conversation

@sipa
Copy link
Member

@sipa sipa commented Nov 3, 2014

These cause too much nagging that make comments about correctness go lost in the noise.

@laanwj
Copy link
Member

laanwj commented Nov 3, 2014

Ah yes, I was intending to do this for a while. ACK.

@laanwj
Copy link
Member

laanwj commented Nov 3, 2014

I think even with this we should split up the review of difficult pulls into two phases:

  • In the first phase, we allow only only commentary on the correctness of the code and the overall concept
  • Then just before merging we can go into a "clean up" phase, and nit about extra spaces, indentation, comment style and other minor details

@laanwj laanwj added the Docs label Nov 3, 2014
@jgarzik
Copy link
Contributor

jgarzik commented Nov 3, 2014

ACK

@Diapolo
Copy link

Diapolo commented Nov 3, 2014

Fell free to do that, I just think it's anoying to make such nits for core devs anyway. If all would use this convention, it wouldn't even cause the need for a "cleanup phase" nor the need for such a pull ;).

It's also likely that not many will ever contribute to such a cleanup phase... if the intention is: "Please Dia don't always "spam" our pulls with nits!" I'm fine with that, but will rethink my motivation to improve code quality (style wise ^^) for this project.

@gavinandresen
Copy link
Contributor

ACK.

Please Dia don't always spam our pulls with nits.

gavinandresen added a commit that referenced this pull request Nov 3, 2014
Remove file and class order guidelines
@gavinandresen gavinandresen merged commit c969096 into bitcoin:master Nov 3, 2014
@laanwj
Copy link
Member

laanwj commented Nov 3, 2014

@Diapolo Yes, if everyone would keep exactly to the convention. But we're human, not robots (ok, speaking just for me). While thinking deeply about how code and data structures should work, reordering and writing new code, it's easy to make a stylistic "mistake" here and there. Focusing too much on them is distracting. This is true during review as well.

I'm not sure how to handle this better - the two-phase approach is just a proposal that may not actually work either - but 'Please Dia don't always spam our pulls with nits' sounds good to me for now.

@jgarzik
Copy link
Contributor

jgarzik commented Nov 3, 2014

Indeed. Referencing the Linux kernel, there were periodic cleanup patches from "janitors" who are typically just entering the codebase / learning the code. This is better than nagging on every PR.

@sipa
Copy link
Member Author

sipa commented Nov 3, 2014

At Google there were very strict rules about ordering of includes etc, and this worked well. But that was with automatic tools for reordering, and their code-review tool would tell you about this immediately (and many more things), so it was much easier to make sure that everybody always knows and used the same system.

Here we tried, and I don't think the benefits are worth the effort.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants