📅 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
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 02:04:34
in reply to nevent1q…e7kz
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 02:04:34Event JSON
{
"id": "f358bdf9f40294434c4a1e30c047944dee0ebd449065f66dd0753e9b8647f6be",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686103474,
"kind": 1,
"tags": [
[
"e",
"4eaf1439aa67825cabdea581be3956c38ea4a62226b60d5367bace64dca7945b",
"",
"root"
],
[
"e",
"a112fb58fb10f345511b07733b06275b7b5a59f34f177f3ede30c01f0e235cab",
"",
"reply"
],
[
"p",
"1ff44081309d1630c10d6c98e652a908562fdfc06fd3def22ca78c6c1aa9cee0"
]
],
"content": "📅 Original date posted:2011-07-12\n🗒️ 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.\n📝 Original message:On Tue, Jul 12, 2011 at 12:13 AM, Alan Grimes \u003cagrimes at speakeasy.net\u003e wrote:\n\u003e While spying on the old code, I noticed one major problem that could be\n\u003e fixed quite easily. That is, the 1 class-per .h/.cpp rule is completely\n\u003e ignored in main.h/cpp and net.h/cpp If all of the classes in the project\n\u003e were re-factored to their own files,\n\nThis is about the last thing we should do, and it's one of the worst\ncoding practices of many C++ projects (and unfortunately carried over\nto Java by force). See Knuth and his work on literate programming.\nPutting logically similar code -together- is often more impactful and\nmeaningful than splitting up files into dozens (hundreds or thousands,\nin large projects) of tiny, 20-line files.\n\nA project attains zen in the -balance-. Bitcoin was not well served\nby \"everything in main.cpp\" approach -- but neither is it well served\nby splitting wallet / transaction / etc. logic across a great many\nfiles. We should not have to ask ourselves, Is This Code In\nWalletFactory.cpp, WalletTx.cpp, WalletStore.cpp, WalletKey.cpp,\nWalletCrypt.cpp, or in s/$F.cpp/$F.h/ ?\n\nStrict, unthinking rules do not buy anything, and can cost us much.\n\nPlus, no matter how you slice it, bitcoin is Hard To Learn and there's\nno getting around that.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "d4ff9ddc01b6d4750e24591d54ee9f7e1c67268ee51e5d370b0887de94aec961278adfe27427b40fdacf8692eb8420a8300fcb204667a91cb678700086c93e86"
}