From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QgVNf-0001uR-1n for bitcoin-development@lists.sourceforge.net; Tue, 12 Jul 2011 05:19:35 +0000 X-ACL-Warn: Received: from mail-iy0-f175.google.com ([209.85.210.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QgVNd-0005or-TI for bitcoin-development@lists.sourceforge.net; Tue, 12 Jul 2011 05:19:35 +0000 Received: by iym10 with SMTP id 10so5887047iym.34 for ; Mon, 11 Jul 2011 22:19:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.20.133 with SMTP id f5mr4921320ibb.197.1310447968454; Mon, 11 Jul 2011 22:19:28 -0700 (PDT) Received: by 10.231.35.67 with HTTP; Mon, 11 Jul 2011 22:19:28 -0700 (PDT) X-Originating-IP: [99.173.148.118] In-Reply-To: <4E1BC9D0.3080104@speakeasy.net> References: <97305540.4426247.1310337435268.JavaMail.fmail@mwmweb052> <201107102201.53937.luke@dashjr.org> <4E1BC9D0.3080104@speakeasy.net> Date: Tue, 12 Jul 2011 01:19:28 -0400 Message-ID: From: Jeff Garzik To: Alan Grimes Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QgVNd-0005or-TI 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 05:19:35 -0000 On Tue, Jul 12, 2011 at 12:13 AM, Alan Grimes wrote: > While spying on the old code, I noticed one major problem that could be > fixed quite easily. That is, the 1 class-per .h/.cpp rule is completely > ignored in main.h/cpp and net.h/cpp If all of the classes in the project > were re-factored to their own files, This is about the last thing we should do, and it's one of the worst coding practices of many C++ projects (and unfortunately carried over to Java by force). See Knuth and his work on literate programming. Putting logically similar code -together- is often more impactful and meaningful than splitting up files into dozens (hundreds or thousands, in large projects) of tiny, 20-line files. A project attains zen in the -balance-. Bitcoin was not well served by "everything in main.cpp" approach -- but neither is it well served by splitting wallet / transaction / etc. logic across a great many files. We should not have to ask ourselves, Is This Code In WalletFactory.cpp, WalletTx.cpp, WalletStore.cpp, WalletKey.cpp, WalletCrypt.cpp, or in s/$F.cpp/$F.h/ ? Strict, unthinking rules do not buy anything, and can cost us much. Plus, no matter how you slice it, bitcoin is Hard To Learn and there's no getting around that. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com