An Experiment on Code Structure
pboyd.io
An Experiment on Code Structure
1–10 of 62 posts
Re: An Experiment on Code Structure
#2Even though the results weren't terribly illuminating, I have to give the author a lot of credit for even attempting to do a proper experiment like this. So much of our programming dogma is based on gut feelings ("it looks cleaner") rather than empirical data and peer-reviewed studies. We have very vague notions of what works, and even vaguer notions of why those things work.
Re: An Experiment on Code Structure
#3Not everyone has a master craftsman in them. Some people will show up in a new code base and need to do something; their first instinct will be to look around and try to fit their change in with the established conventions.
They are the minority.
Most will show up and handjam their change in the only way they know how. There will be no concern for the forest. Their job is processing trees after all.
This is something that was on my mind in the Google PR review thread. Not everyone is a "peer" in code reviews. There will be a certain cabal on equal footing, but there will be many more people who are simply contributors.
This is where people like the author come in; Project leads.
Re: An Experiment on Code Structure
#4Even though the results weren't terribly illuminating, I have to give the author a lot of credit for even attempting to do a proper experiment like this. So much of our programming dogma is based on gut feelings ("it looks cleaner") rather than empirical data and peer-reviewed studies. We have very vague notions of what works, and even vaguer notions of why those things work.
[dead]
Re: An Experiment on Code Structure
#5According to GitHub, the totals are:
backendA: 11 files, 1 directory, 799 lines (676 sloc), 23.56KB
backendB: 23 files, 5 directories, 1578 lines (1306 sloc), 42.26KB
It's approximately twice as big for the same functionality, and I had to spend a lot more time "digging" through the second one to get an overall idea of how everything works. Jumping around between lots of tiny files is a big waste of time and overhead, and one of the pet peeves I have with a lot of how "modern" software is organised. If you believe that the number of bugs is directly proportional to the number of lines of code, thus "less code, fewer bugs", then backendA is far superior.
backendB required a bit more work
I'm not surprised that it did. This experiment reminds me of the "enterprise Hello World" parodies, and although backendB isn't quite as extreme, it has some indications of going in that direction. The excessive bureaucracy of Enterprise Java (and to a lesser extent, C#) leads to even simple changes requiring lots of "threading the data" through many layers. I've worked with codebases like that before, many years ago, and don't ever wish to do it again.
I really don't get this fetish for lots of tiny files and nested directories, which seems to be a recent trend; "maintainability" is often dogmatically quoted as the reason, but when it comes time to actually do something to the code, I much prefer a few larger files in a flat structure, where I can scroll through and search, instead of jumping around lots of tiny files nested several directories deep. It might look simpler at the micro level if each file is tiny, or the functions in them are also very short, but all that means is the complexity of the system has increased at the macro level and largely become hidden in the interaction of the parts.
Re: An Experiment on Code Structure
#6Even though the results weren't terribly illuminating, I have to give the author a lot of credit for even attempting to do a proper experiment like this. So much of our programming dogma is based on gut feelings ("it looks cleaner") rather than empirical data and peer-reviewed studies. We have very vague notions of what works, and even vaguer notions of why those things work.
I’ve come to the conclusion that half or more of the rules we have about “clean” are about avoiding merge conflicts. Few things have been consistently disappointing to me as the inability of coworkers and myself to reason about merges correctly. There are three hard things in software and merges are #3.
If anyone ever figures out how to make merges Just Work, then I expect a lot of pressure toward decomposition over locality would be reduced, and much of the rest would be to facilitate testing.
Re: An Experiment on Code Structure
#7Not everyone has a master craftsman in them. Some people will show up in a new code base and need to do something; their first instinct will be to look around and try to fit their change in with the established conventions. They are the minority. Most will show up and handjam their change in the only way they know how. There will be no concern for the forest. Their job is processing trees after all. This is something…
What gets me is that people are willing to write the same code dozens of times. It’s just a tool in their toolbox. It never seems to occur to them that our job is substantially about automating predicable things.
Re: An Experiment on Code Structure
#8According to GitHub, the totals are: backendA: 11 files, 1 directory, 799 lines (676 sloc), 23.56KB backendB: 23 files, 5 directories, 1578 lines (1306 sloc), 42.26KB It's approximately twice as big for the same functionality, and I had to spend a lot more time "digging" through the second one to get an overall idea of how everything works. Jumping around between lots of tiny files is a big waste of time and overhead…
Splitting things up into multiple independent translation units enables incremental compilation. One function per file is the most extreme version of this. For example:
Re: An Experiment on Code Structure
#9Even though the results weren't terribly illuminating, I have to give the author a lot of credit for even attempting to do a proper experiment like this. So much of our programming dogma is based on gut feelings ("it looks cleaner") rather than empirical data and peer-reviewed studies. We have very vague notions of what works, and even vaguer notions of why those things work.
I’ve come to the conclusion that half or more of the rules we have about “clean” are about avoiding merge conflicts. Few things have been consistently disappointing to me as the inability of coworkers and myself to reason about merges correctly. There are three hard things in software and merges are #3. If anyone ever figures out how to make merges Just Work, then I expect a lot of pressure toward decomposition over…
Can you elaborate a little please? It's unclear to me if you are taking about merging data, code changes, or something else
Re: An Experiment on Code Structure
#10According to GitHub, the totals are: backendA: 11 files, 1 directory, 799 lines (676 sloc), 23.56KB backendB: 23 files, 5 directories, 1578 lines (1306 sloc), 42.26KB It's approximately twice as big for the same functionality, and I had to spend a lot more time "digging" through the second one to get an overall idea of how everything works. Jumping around between lots of tiny files is a big waste of time and overhead…
Splitting things up into multiple independent translation units enables incremental compilation. One function per file is the most extreme version of this. For example: https://git.musl-libc.org/cgit/musl/tree/src/stdio
That seems like a problem for compiler optimizers to solve, not programmers.