Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QgXHT-0006gW-9S for bitcoin-development@lists.sourceforge.net; Tue, 12 Jul 2011 07:21:19 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.47 as permitted sender) client-ip=209.85.218.47; envelope-from=witchspace81@gmail.com; helo=mail-yi0-f47.google.com; Received: from mail-yi0-f47.google.com ([209.85.218.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QgXHS-0003x2-EC for bitcoin-development@lists.sourceforge.net; Tue, 12 Jul 2011 07:21:19 +0000 Received: by yib18 with SMTP id 18so2377948yib.34 for ; Tue, 12 Jul 2011 00:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.118.19 with SMTP id v19mr4798493ybm.300.1310455273004; Tue, 12 Jul 2011 00:21:13 -0700 (PDT) Received: by 10.151.150.15 with HTTP; Tue, 12 Jul 2011 00:21:12 -0700 (PDT) In-Reply-To: References: <97305540.4426247.1310337435268.JavaMail.fmail@mwmweb052> Date: Tue, 12 Jul 2011 07:21:12 +0000 Message-ID: From: John Smith To: Mike Hearn Content-Type: multipart/alternative; boundary=001e680f157c0aa05104a7da2575 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1QgXHS-0003x2-EC Cc: bitcoin-development@lists.sourceforge.net, Michael Offel Subject: Re: [Bitcoin-development] overall bitcoin client code quality X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 07:21:19 -0000 --001e680f157c0aa05104a7da2575 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 11, 2011 at 9:33 AM, Mike Hearn wrote: > > My overall suggestion is to begin a complete rewrite, inspired by the old > > code rather than moving a lot of "known to be somehow functional" around. > > This essay is old but still relevant, I think: > > http://www.joelonsoftware.com/articles/fog0000000069.html > +1 More code documentation would be helpful, and so would making the interfaces more understandable/readable, and getting rid of the manual locking (especially in client code!), but I don't see how that would warrant a complete rewrite. Some refactoring would be much safer than trying to reproduce every nook and cranny in a rewrite. re:4) I also don't see why boost would be a 'nonstandard dependency'. From what I understand, a large part of the new C++0x standard is derived from boost. Also C++ compilers are getting faster and more smart all the time, so I absolutely don't see "build speed" as a goal. re:6) I've already submitted a few pull requests that replace hardcoded magic values with constants. Moving the constants to a config file is not needed IMO because the end-user doesn't need to change them. JS --001e680f157c0aa05104a7da2575 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 11, 2011 at 9:33 AM, Mike He= arn <mike@plan99.ne= t> wrote:
> My overall suggestion is to begin a complete rewrite= , inspired by the old
> code rather than moving a lot of "known to be somehow functional&= quot; around.

This essay is old but still relevant, I think:

=A0http://www.joelonsoftware.com/articles/fog0000000069.html<= /a>


+1

More code documentation would be= helpful, and so would=20 making the=20 interfaces more understandable/readable, and getting rid of the manual=20 locking (especially in client code!), but I don't see how that would=20 warrant a complete rewrite.

Some refactoring would be much safer tha= n trying to reproduce every nook and cranny in a rewrite.

re:4) I also don't see why boost would be a 'nonstandard dependency'= . From=20 what I understand, a large part of the new C++0x standard is derived=20 from boost. Also C++ compilers are getting faster and more smart all the time, so I absolutely don't see "build speed" as a goal.

re:6) I've already submitted a few pull requests that replace=20 hardcoded magic values with constants. Moving the constants to a config=20 file is not needed IMO because the end-user doesn't need to change them= .

JS

--001e680f157c0aa05104a7da2575--