From: Gregory Maxwell <gmaxwell@gmail•com>
To: Michael Offel <michael.offel@web•de>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
Date: Tue, 12 Jul 2011 19:40:46 -0400 [thread overview]
Message-ID: <CAAS2fgQfA6O+jrk7LF4p7mjoYOVm2rSOJYJbqr6oTiFYVbaVkQ@mail.gmail.com> (raw)
In-Reply-To: <602127524.20110712224712@web.de>
On Tue, Jul 12, 2011 at 5:47 PM, Michael Offel <michael.offel@web•de> wrote:
> We seem to have very different opinions on that, but let's try to be
> objective. I belive that every class should be able to stand on its
> own. That way it can be reused in other projects or situations in the
> same project. And it is much more easy 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— I'm sure many people value your ideas
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— 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 it even gives some kind of easier to read history and fewer
> merge conflicts. When you start writing a class for exactly one
> propose in one 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.)
next prev parent reply other threads:[~2011-07-12 23:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-12 21:47 Michael Offel
2011-07-12 23:40 ` Gregory Maxwell [this message]
2011-07-13 0:17 ` Matt Corallo
2011-07-13 11:50 ` Mike Hearn
2011-07-13 13:04 ` Andy Parkins
2011-07-13 18:37 ` Luke-Jr
2011-07-13 21:41 ` Andy Parkins
-- strict thread matches above, loose matches on Subject: below --
2011-07-10 22:37 Michael Offel
2011-07-10 23:07 ` Douglas Huff
2011-07-10 23:31 ` Jeff Garzik
2011-07-10 23:36 ` Matt Corallo
2011-07-11 2:01 ` Luke-Jr
2011-07-12 4:13 ` Alan Grimes
2011-07-12 5:19 ` Jeff Garzik
2011-07-11 9:33 ` Mike Hearn
2011-07-12 3:31 ` Gavin Andresen
2011-07-12 7:21 ` John Smith
2011-07-12 22:50 ` Michael Offel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgQfA6O+jrk7LF4p7mjoYOVm2rSOJYJbqr6oTiFYVbaVkQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=michael.offel@web$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox