ensure alphabetical include file ordering #4456

pull Diapolo wants to merge 1 commits into bitcoin:master from Diapolo:include changing 10 files +15 −15

Diapolo commented at 10:34 AM on July 2, 2014: none

@laanwj That one should be really easy now ;).
ensure alphabetical include file ordering 329dab5a7b
BitcoinPullTester commented at 10:52 AM on July 2, 2014: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4456_329dab5a7badce04a9af55740cbb8cd59edc4a3b/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
in src/txmempool.cpp:None in 329dab5a7b
```
   2 | @@ -3,9 +3,10 @@
   3 |  // Distributed under the MIT/X11 software license, see the accompanying
   4 |  // file COPYING or http://www.opensource.org/licenses/mit-license.php.
   5 |  
   6 | -#include "core.h"
   7 |  #include "txmempool.h"
   8 |  
   9 | +#include "core.h"
```
laanwj commented at 5:58 AM on July 3, 2014:

Huh? This seems reversed...

sipa commented at 10:14 AM on July 3, 2014:

A .cpp file includes its corresponding .h file as first one. At least, that's what seems to be the intention.

laanwj commented at 10:24 AM on July 3, 2014:

Oh, of course
jgarzik commented at 12:55 PM on July 3, 2014: contributor

This just seems like it is pointlessly stirring the code.
rebroad commented at 1:18 PM on July 3, 2014: contributor

agree with @jgarzik plus I don't see people keeping to this "standard".
Diapolo commented at 2:48 PM on July 4, 2014: none

I try to ensure some standards yes, it makes things IMHO more logical and easier to read... seems (nearly) no one cares or is admitted to it.
gavinandresen commented at 2:50 PM on July 4, 2014: contributor

Closing.

I believe code should only be stirred when you're improving it somehow (fixing a bug, implementing a new feature, or refactoring to make fixing a bug or implementing a new feature easier).
gavinandresen closed this on Jul 4, 2014
Diapolo commented at 2:57 PM on July 4, 2014: none

@gavinandresen Even when I do that "everyone" is screaming... no one really cares how our code looks, this is absurd.
jgarzik commented at 3:51 PM on July 4, 2014: contributor

Just like in other areas of life, you must prioritize. Find a balance.

Obviously we all care, otherwise prior cleanups would not have been merged. There is near-universal agreement on IRC that we inherited a grotty codebase that needs much refactoring.

Code stirring has very real costs which cannot be ignored. Every cosmetic patch potentially breaks a more useful pull request, costing others time down the road.

Cosmetic patches cost very little to create, so it is easy to create lots of them versus more substantive pull requests.
Diapolo deleted the branch on Jul 15, 2014
MarcoFalke locked this on Sep 8, 2021

Contributors