MIME-Version: 1.0
In-Reply-To: <4E1BC9D0.3080104@speakeasy.net>
References: <97305540.4426247.1310337435268.JavaMail.fmail@mwmweb052>
	<201107102201.53937.luke@dashjr.org>
	<4E1BC9D0.3080104@speakeasy.net>
Date: Tue, 12 Jul 2011 01:19:28 -0400
Message-ID: <CA+8xBpcu8dT54sPKCJyjdEcYD=TWsrNx80fjj4S9qtq_XzcFOQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Alan Grimes <agrimes@speakeasy.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
Precedence: list

On Tue, Jul 12, 2011 at 12:13 AM, Alan Grimes <agrimes@speakeasy.net> wrote:
> While spying on the old code, I noticed one major problem that could be
> fixed quite easily. That is, the 1 class-per .h/.cpp rule is completely
> ignored in main.h/cpp and net.h/cpp If all of the classes in the project
> were re-factored to their own files,

This is about the last thing we should do, and it's one of the worst
coding practices of many C++ projects (and unfortunately carried over
to Java by force).  See Knuth and his work on literate programming.
Putting logically similar code -together- is often more impactful and
meaningful than splitting up files into dozens (hundreds or thousands,
in large projects) of tiny, 20-line files.

A project attains zen in the -balance-.  Bitcoin was not well served
by "everything in main.cpp" approach -- but neither is it well served
by splitting wallet / transaction / etc. logic across a great many
files.  We should not have to ask ourselves, Is This Code In
WalletFactory.cpp, WalletTx.cpp, WalletStore.cpp, WalletKey.cpp,
WalletCrypt.cpp, or in s/$F.cpp/$F.h/ ?

Strict, unthinking rules do not buy anything, and can cost us much.

Plus, no matter how you slice it, bitcoin is Hard To Learn and there's
no getting around that.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com