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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1QgmZQ-0002ce-Li
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Jul 2011 23:40:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
helo=mail-qw0-f47.google.com;
Received: from mail-qw0-f47.google.com ([209.85.216.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QgmZP-0007ZU-UQ
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Jul 2011 23:40:52 +0000
Received: by qwh5 with SMTP id 5so1466663qwh.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 Jul 2011 16:40:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.43.225 with SMTP id x33mr492038qce.64.1310514046446; Tue,
12 Jul 2011 16:40:46 -0700 (PDT)
Received: by 10.229.83.196 with HTTP; Tue, 12 Jul 2011 16:40:46 -0700 (PDT)
In-Reply-To: <602127524.20110712224712@web.de>
References: <602127524.20110712224712@web.de>
Date: Tue, 12 Jul 2011 19:40:46 -0400
Message-ID: <CAAS2fgQfA6O+jrk7LF4p7mjoYOVm2rSOJYJbqr6oTiFYVbaVkQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Michael Offel <michael.offel@web.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1QgmZP-0007ZU-UQ
Cc: bitcoin-development@lists.sourceforge.net
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 23:40:52 -0000
On Tue, Jul 12, 2011 at 5:47 PM, Michael Offel <michael.offel@web.de> wrote=
:
> We =C2=A0seem =C2=A0to have very different opinions on that, but let's tr=
y to be
> objective. =C2=A0I =C2=A0belive =C2=A0that every class should be able to =
stand on its
> own. =C2=A0That way it can be reused in other projects or situations in t=
he
> same =C2=A0project. =C2=A0And =C2=A0it =C2=A0is =C2=A0much =C2=A0more eas=
y to catch and extend class
Objectively, your believes have only the weight of the electrons they are
printed on, so long as you're talking and not coding.
I don't mean that as an insult=E2=80=94 I'm sure many people value your ide=
as
but when you disagree with someone who is actually coding you'll
eventually lose every time. Talk is cheap.
(And I'm guilty of this too=E2=80=94 but aware of my lacking commits I'm
certainly not going to expect anyone to listen to _coding style_ advice.
I try to keep my comments to crap I can measure and speculate about.)
[snip]
> In terms of source
> control =C2=A0it =C2=A0even =C2=A0gives some kind of easier to read histo=
ry and fewer
> merge =C2=A0conflicts. =C2=A0When =C2=A0you =C2=A0start =C2=A0writing =C2=
=A0a =C2=A0class for exactly one
> propose =C2=A0in =C2=A0one specific situation used by one other class you=
should
Certainly no modern SCM has major issues with merge conflicts due to
shared files.
Bitcoin is a _tiny_ piece of software... on the order of 20kloc. It's a
a scale where someone competent can read it in a day and have a basic
overall understanding of it in a few.
This fact makes the aesthetics talk seem like pointless shed-painting
especially coming from people who are yet doing substantial work.
The proposal about reimplementing parts as libraries and the switching
to them after validating them is a fine one. I suggest you do it.
Having multiple work on such projects would not be wasted effort,
as we'd all learn from the competition in designs/APIs/and targets for
comparative testing.
The interesting logic, however, is not net.cpp... because nothing too
awful happens if peers get confused and drop their connections here
and there. The critical logic is the blockchain validation logic. Which
must make absolutely identical decisions on all nodes and which has a
lot of corner cases which are difficult to test and might expose
behavioral differences.
There is also a lot of neat functionality in the scripts which is
currently disabled because of a lack of confidence about the
security of that code.
So not only are new, clean, secondary implementations of this logic
needed, but good automatic testing shims which can find
inconsistencies between implementations.
(Testing rigs are often an excellent area of work for people new to
a project.)
|
