Enable flake8 rule E231. #14540

1. 
   jbampton commented at 10:34 pm on October 21, 2018: contributor

   Checks for missing whitespace after ‘,’, ‘;’, or ‘:’

   Lint Python code for rule E231.

2. Enable flake8 rule E231.

   Checks for missing whitespace after ‘,’, ‘;’, or ‘:’

   5e6d1724bb
3. fanquake added the label Tests on Oct 21, 2018
4. MarcoFalke closed this on Oct 22, 2018

   ---

5. 
   MarcoFalke commented at 0:46 am on October 22, 2018: member

   Thanks for your contribution, but pull requests without a rationale and clear improvement may be closed immediately.

   Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.

   • Any test improvements or new tests that improve coverage are always welcome.
   • All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
   • Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
   • Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
   • Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most “code style” refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.

   Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.

6. 
   MarcoFalke commented at 0:46 am on October 22, 2018: member

   Thanks for your contribution, but pull requests without a rationale and clear improvement may be closed immediately.

   Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.

   • Any test improvements or new tests that improve coverage are always welcome.
   • All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
   • Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
   • Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
   • Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most “code style” refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.

   Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.

7. 
   MarcoFalke commented at 0:47 am on October 22, 2018: member

   Thanks for your contribution, but pull requests without a rationale and clear improvement may be closed immediately.

   Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.

   • Any test improvements or new tests that improve coverage are always welcome.
   • All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
   • Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
   • Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
   • Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most “code style” refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.

   Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.

8. 
   MarcoFalke commented at 0:47 am on October 22, 2018: member

   Thanks for your contribution, but pull requests without a rationale and clear improvement may be closed immediately.

   Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.

   • Any test improvements or new tests that improve coverage are always welcome.
   • All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
   • Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
   • Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
   • Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most “code style” refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.

   Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.

9. 
   MarcoFalke commented at 0:49 am on October 22, 2018: member

   Thanks for your contribution, but pull requests without a rationale and clear improvement may be closed immediately.

   Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.

   • Any test improvements or new tests that improve coverage are always welcome.
   • All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
   • Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
   • Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
   • Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most “code style” refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.

   Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.

10. jbampton deleted the branch on Oct 14, 2019
11. MarcoFalke locked this on Dec 16, 2021

Contributors
jbampton MarcoFalke

Labels
Tests