Author: Michael Offel 2011-07-12 21:47:12
Published on: 2011-07-12T21:47:12+00:00
The context centers around a discussion thread from July 2011 in the Bitcoin community. During the discussion, various aspects of the Bitcoin client codebase were debated. Jeff Garzik proposed using "libbitcoin" and suggested starting with a small module to implement in a branch. Matt Corallo discussed the decision to use Berkeley db 4 and suggested an alternative of storing file offsets in an STL map. The group also debated creating a chain description file for adjustable parameters and the importance of having clean, well-documented code.Luke-Jr suggested beginning a complete rewrite of the codebase, while Gavin Andresen proposed stopping Bitcoin usage for six months to implement a better client. Finally, Jeff Garzik defended the practice of putting logically similar code together rather than splitting it up into many tiny files.One point of discussion was the benefits of isolating class behavior to one file instead of mixing it between other class methods or having multiple files. The author argues that having 50-80 code files in Bitcoin may not be bad since it provides an easier-to-read history and fewer merge conflicts. Writing a nested class for exactly one purpose in one specific situation used by one other class can achieve similar code in one location while accepting the rule others like. It also allows seeing a class dependency list by looking at the include listing.The author believes that if Boost would be used for something meaningful, there would be no point in removing it. However, everything non-questionable about Boost already finds its way into most STL implementations. Everything that finds its way into C++ 0x does it for the reason that it is better handled by a language extension than by a Boost construct.
Updated on: 2023-05-26T19:21:22.435372+00:00