Bitcoin source code is a giant mess

[CIYAM]

Close enough to have a working goto...

Hmm... am not really sure about that (and no C++ guru would ever recommend using it) - the problem is that the compiler needs to handle all the object dtors correctly (the reason why it is *not easier for the compiler*).

I am not sure that g++ (or other major compilers) give such a guarantee.

It's a bit like using *void* pointers (another common C idiom that is *bad* in C++).

[jdbtracker]

I don't know how to program C++, but I can tell from what I do know that the Bitcoin system feels intentionally limited.

the block chain limit of 1mb... creates fee scarcity fluctuations; The limit will be hit sooner and economic effects from the fees will be visible once we get close to it.

the size of the coin limit of 21 million, if it had been 210 million with 500 coin initial block release, the price would more easily be able to handle large fluctuations a far smoother accent to it's final value.Having the limit that small to me feels like it was done intentionally for experimental observations, more scarcity econonomics.

also the number of zeros past the period also feels like a mistake with large disparities in value between two currencies it becomes very difficult to transfer financial information when large chunks of an economy are absorbed, Think along the lines of 100 trillion yen cap value to bitcoin with someone trying to exchange a small amount to a country like zimbabwe with a 1million/1USD value... there are not enough digits to transfer the value accurately in that situation, you'd be limited to doing 100 thousand zimbabwe dollar transaction... what if you can buy a cup of coffee in zimbabwe with 100 Z dollars? you wouldn't be able to do the micro-transaction.

10 minute confirms? when transactions can go around the globe in under a second. with a 1mb limit every 1 minute it could more effectively use the network overall power and increase security on a timed basis.

It would not surprise me that the code was written intentionally for big problems to occur much sooner, for expermentation... Bitcoin really is an experiment, the limits it has are made to cause instability intentionally or to observe data fluctuations more easily. The code itself could be flawed and vague on purpose.

So what is everyone doing to improve these possibly intentional limitations?

[misterbigg]

...

Completely off-topic. This post is only about the form of the code and not its content (which is equally important, but not the subject of this thread).

[jdbtracker]

it ties into the topic,

What are the problems that the code creates? What problems will it cause?

[misterbigg]

it ties into the topic, What are the problems that the code creates? What problems will it cause?

Hard to read, harder to change without breaking something.

[jgarzik]

The fact that goto has been used badly doesn't make it a bad instrument: it's a great instrument if you know exactly when to use or not use it.

Donald Knuth and Linus Torvalds both agree with this sentiment.  

Just like any other tool, you have to know when to use it, and when not to use it.

[Mike Hearn]

If you're working on a native Mac wallet, you might want to contact Colin Tulloch. He's also exploring this. I've been trying to convince him to use bitcoinj compiled down to native code with GCJ/CNI. I prototyped this last year and got an Objective-C++ app that could load bitcoinj wallets up and running, the end result was a native .app without any Java dependencies. Unfortunately for various reasons I stopped rebasing that branch and the support wasn't fully documented or integrated into bitcoinj. But writing a real SPV wallet app is a lot of work, so reusing the work we've done in the Java world makes a ton of sense. From the code perspective it looks like writing C++ except you don't need to delete objects and the API uses jstrings instead of std::string or NSString.

[misterbigg]

Donald Knuth and Linus Torvalds both agree with this sentiment.   Just like any other tool, you have to know when to use it, and when not to use it.

Bitcoin source is by no means even remotely close to being a model of C++ exposition. Expedience always takes priority over tidiness.

[oleganza]

2. Excessive use of C++ subclasses and operators makes it hard to read code. You see a << b, but it actually goes to a very specific place which is not entirely obvious where.

Streaming operators << and >> have always been the standard way of doing I/O in C++ so are you saying these operators are being used for something *other than streaming*?

I have nothing against using << as a streaming operator. The problem is that it's much harder to search for any operators in use (be it "<<" or "+"). Especially when you pointer-dereference operator overload. Or implicit copy constructors. Yes, code may look elegant for a mathematician, but inside an app where you have tons of multi-word symbols, operator density or implicitness is painful.

When you have "[a add:b]" instead of "a + b" it's much clearer what is going on and you can quickly find all occurrences of -add: method call.

[piotr_n]

2. Excessive use of C++ subclasses and operators makes it hard to read code. You see a << b, but it actually goes to a very specific place which is not entirely obvious where.

Streaming operators << and >> have always been the standard way of doing I/O in C++ so are you saying these operators are being used for something *other than streaming*?

I have nothing against using << as a streaming operator. The problem is that it's much harder to search for any operators in use (be it "<<" or "+"). Especially when you pointer-dereference operator overload. Or implicit copy constructors. Yes, code may look elegant for a mathematician, but inside an app where you have tons of multi-word symbols, operator density or implicitness is painful.

When you have "[a add:b]" instead of "a + b" it's much clearer what is going on and you can quickly find all occurrences of -add: method call.

+1
I also hate these symbols, because of the same reason.
You just cannot find a function that implements it. And worse; it can either be in a header, or in a cpp file... and it can be overridden/inherited, so: good luck looking for it!

[sickpig]

Presented without comment:



link (github.com)

Linux kernel use goto quite extensively

[mmeijeri]

Let's not turn this into a C++ coding standards discussion.

[willphase]

I would suggest that if you see problems with the bitcoin codebase, you submit a patch (and appropriate tests for your patch) via the bitcoin github, and make the codebase better!  The code is open source!

Will

[mmeijeri]

We're far beyond that point. The code needs very thorough restructuring. That can be done incrementally, even while others are adding functionality, but I think it is going to be very hard to get a consensus on the needed changes.

[2112]

We're far beyond that point. The code needs very thorough restructuring. That can be done incrementally, even while others are adding functionality, but I think it is going to be very hard to get a consensus on the needed changes.

The consesus about the needed changes could conceivably be that the official Bitcoin client switches from the "Satoshi legacy C++" to one of the newer candidate codebases, e.g. the Java code from Hungary.

For me it is good to read more and more comments about the need to stop treating Satoshi (and his legacy code base and protocol) as an inviolate revelation and more as an ingenious sketch of the future.

Time for me to repost my favourite picture of an amber:

It is an ambodiment of both the mess and the beauty.

[CIYAM]

Linux kernel use goto quite extensively

Am pretty sure that it is C not C++ (and yes they are two very different languages).

[mmeijeri]

Switching to another codebase is certainly one possibility,  but refactoring the existing code is also a realistic option. Starting with a good test harness around bitcoind would be a good start for both options. And the existence of an API makes this a lot easier.

[LvM]

Worst problem of BTC is not the code but the basic "cash/change" logic ignoring all fundamentals of GAAP.
Ripple -though in this respect much better structured- cannot be trusted due to many other reasons.

[oleganza]

Worst problem of BTC is not the code but the basic "cash/change" logic ignoring all fundamentals of GAAP.
Ripple -though in this respect much better structured- cannot be trusted due to many other reasons.

Can you expand on cash/change problem? What's wrong with it?

[mmeijeri]

Not again, he already has his own thread.