Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-12 🗒️ Summary of this message: A suggestion ...

📅 Original date posted:2011-07-12
🗒️ Summary of this message: A suggestion was made to refactor all classes in a project to their own files, but Jeff Garzik argues that putting logically similar code together is often more impactful and meaningful.
📝 Original message:On Tue, Jul 12, 2011 at 12:13 AM, Alan Grimes <agrimes at speakeasy.net> 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 at exmulti.com