It's easy to complain about code. But unless a person can show that they did something better, they have no moral authority to complain.

There is no object oriented design. Basically there is one big global state and that's it.

Very specifically line 24 in my SVN chechout contains the following number, but there is no explanation as to why this number is there; I can guess why it is there, but it shouldn't be my task to figure out why something is there. A comment above this constant should say why exactly it is that value and not some other value, why it is important for the system, etc.

Additionally a comment should state which hashing function is being used. E.g. it should say "The magic constant below is equal to the sha256sum (See, <reference to original definition of this algorithm>) of value <myvalue>. This is done, because <insert reasons>. "
 

There is also no need to create a 3200 lines long source file. There is just no reason to do that other than to discourage people from making the effort to understand it.

I am sure it is possible to reverse-engineer it in a few months to get it into a state in which one can just read through the whole program in an hour or so, but that's not the same as it already being in such a state.

Anyway, I hope you see the difference in approach.

Monolithic, code in header files, all units very tightly coupled, misuse of templates (when simple inheritance would do).

I started cleaning up the code. The repo is at http://bitbucket.org/hsoft/bitcoin-clean

Well, I guess you're right :  at least ther should be a comment.

But anyway we know Satoshi's code is poorly commented.  It is just an example amonst many others.

A waste of time. If you want to do something really useful for the code, write a test suite for it.

That kind of explains it, you're still learning it. You can say one thing about the bitcoin code, namely is not beginner-friendly at all.

That doesn't work at all for generic programming. You can instantiate for example vector<int>, vector<float>, but then you could only ever use those two.
If you want vector<X> where X is any type to work you need to put the code for vector in a header. It's weird but C++ is designed like that. Again, look at Boost.

Anyway, IMO: there are more important things to worry about right now than Satoshi's code style. Such as building services that accept bitcoin.

This is precisely what I'm trying to do. My main goal is to create Python bindings to bitcoin. I've tried to extract a library out of it (see http://bitcointalk.org/index.php?topic=2075.0 ) but I failed. I'm cleaning the code now because I see it as the only way to achieve my main goal.

Those debates about coding style in C++ are part of the reasons why I've never been much enthusiastic about this language.

What about a plain C implementation of bitcoin ?  Do we really need object paradigm for this anyway ?

But do you really need to re-implement the client to do that? Why not simply use the current client, through JSON-RPC?

hsoft: I do agree that modularizing the current (C++) codebase seems like the best option if you really want to work on the bitcoin client itself. I've seen some good ideas:

• Split into GUI, JSON server, backend library (the libbitcoin idea), which can be built separately.
• Integrate a real build system (based on cmake/autotools/scons...), which autodetects presence/install dir of wxWindows and other deps.
• Add some asynchronous notification mechanism when transactions come in, to prevent polling.
• Build packages for debian/redhat/... and help it getting integrated into the repositories.

IMO: if we alternative bitcoin clients in every possible programming language, just because we like our own language/style better, that doesn't help further the cause of bitcoin itself at all. It's a nerd party only.