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; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>
References: <97305540.4426247.1310337435268.JavaMail.fmail@mwmweb052>
	<CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>
Date: Tue, 12 Jul 2011 07:21:12 +0000
Message-ID: <CAJNQ0svqH9wkbrRpJ-prXH4ue1uz0nG1jqJYkd3WtUjL7GN2EQ@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001e680f157c0aa05104a7da2575
Cc: bitcoin-development@lists.sourceforge.net,
	Michael Offel <Michael.Offel@web.de>
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
Precedence: list

--001e680f157c0aa05104a7da2575
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jul 11, 2011 at 9:33 AM, Mike Hearn <mike@plan99.net> 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

<br><br><div class=3D"gmail_quote">On Mon, Jul 11, 2011 at 9:33 AM, Mike He=
arn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net">mike@plan99.ne=
t</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt; My overall suggestion is to begin a complete rewrite=
, inspired by the old<br>
&gt; code rather than moving a lot of &quot;known to be somehow functional&=
quot; around.<br>
<br>
</div>This essay is old but still relevant, I think:<br>
<br>
 =A0<a href=3D"http://www.joelonsoftware.com/articles/fog0000000069.html" t=
arget=3D"_blank">http://www.joelonsoftware.com/articles/fog0000000069.html<=
/a><br></blockquote><div><br><br>+1<br><br>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&#39;t see how that would=20
warrant a complete rewrite.<br><br>Some refactoring would be much safer tha=
n trying to reproduce every nook and cranny in a rewrite.<br><br>re:4)
 I also don&#39;t see why boost would be a &#39;nonstandard dependency&#39;=
. 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&#39;t see &quot;build speed&quot; as a goal.<br>
<br>re:6) I&#39;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&#39;t need to change them=
.<br>
<br>JS<br><br></div></div>

--001e680f157c0aa05104a7da2575--