Technology is opened and transparent. It's not messy - all you need is strong exprience with modern C++ design, passion and maybe little different attitude to it. (not you personally sure
)
It's not only my opinion - for example i have another dev who was helped me with some core patches (difficulty adjustment from 64 to 128 bit to be more concrete) - he also gave good feedback about codebase. And also it said dga (Dave Andersen) if i'm not mistaken (correct me if i wrong).
I haven't looked at a lot of the core code for things like transactions.
On the whole, I have mixed feelings about it. I can comment on, for example, the wild keccak implementation and the cryptonight PoW implementation:
- CryptoNight was deliberately obfuscated, so it's not a very useful example. It was ugly, but it was someone clever trying to be ugly. The underlying *algorithm* (also invented by CN) was really elegant.
- Wild Keccak was reasonable. It made use of some fancy very-modern C++ features in ways that I might call excessively clever (there's a funky use of a type trait template in there to differentiate the real keccak code from a tweaked version used in the PoW with extra multiplies), but that's a bit more in the realm of style, and I see why it was done that way. (I think that's related to some of my comments below about the code being designed for ease-of-being-written).
- The RPC design is very reasonable. Much better than most of the C-based protocols in other currencies. The use of C++ there helps clean it up a lot, and it's both readable and easier to verify correctness and lack of things like buffer overflows.
- The tree_hash code that PT was complaining about is almost unreadable and very difficult to determine what the heck it's actually trying to do. The lack of comments there are brutal for an outside developer.
- The simpleminer code was mixed. It wasn't commented, but it wasn't too hard to figure out. I only spotted a few issues.
- The code is structurally complex -- understanding it requires too much bouncing between many different files. It would really benefit from a big refactoring that focused on simplification and clarity. It has the feel of code that was written with an eye towards programmer efficiency on *writing* (getting a lot out of relatively few lines of code). Simple examples would be things like "why the heck is get_donation_accounts() in a file called currency_format_utils.cpp" (or the equivalent functions in cryptonote_format_utils for XMR).
The last comment is really the best way to sum up the state of the codebase: My guess is that it was written by folks who know what they're doing, but were focused on developer speed, not the kind of structure that makes it easier to maintain the code over longer periods of time. A lot of that can be fixed with refactoring and (serious) reviews from other developers about where things need to be clarified. Some bits should be shot and rewritten, such as that nasty bit of C that PT identified.
There are some big chunks in C that I haven't looked at, and which I gather are the source of a lot of the horribleness.
But it's not too hard for a good C++ programmer to jump in and start doing some work on the parts of the codebase that *aren't* directly tied to the core transaction stuff. That part will take someone longer to get into, but it's not impossible.
) .