1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
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 <witchspace81@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
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 <Michael.Offel@web.de>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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"><<a href=3D"mailto:mike@plan99.net">mike@plan99.ne=
t</a>></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">> My overall suggestion is to begin a complete rewrite=
, inspired by the old<br>
> code rather than moving a lot of "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'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'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.<br>
<br>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=
.<br>
<br>JS<br><br></div></div>
--001e680f157c0aa05104a7da2575--
|
