Fuzzyset – A Human-Readable Interactive Representation of a Code Library
glench.github.io
glench.github.io
Lately, I find the best way to make my code more comprehensible is just to break it down into smaller pieces. The 300 lines of fuzzyset is pretty good! I find 150 lines is ideal, although I rarely understand the refactoring space well enough to hit that. 300 is more common, and 600-800 is not unheard of for me. And I code in 42 character width, so those are short lines, with smokers whitespace.
Forcing your code into single 150 line JavaScript file with a README and a published interface is a great way to force yourself to really understand the core concern. You squeeze out any and all orthogonal concerns into their own fully independent module. It clarifies the design to the point that the documentation has less to do.
But I’m advocating something much stronger than that: breaking them down into small modules each with a published interface.
You can see what all any given module depends on by looking at one set of imports at the top of one file.
Each of those has a github repo and a README, so it’s easy to find out what they do...
But most importantly, the architecture of such a library will be wholly different than what it would have been if developed as a monorepo.
My point is not really that this structure of code is ergonomic. It’s that forcing yourself to do things this way forces you to clarify the purpose of modules. And to discover interfaces which are truly orthogonal.
And that makes the code easier to understand.
I prefer "meat" separated. And having clear boundaries. 1k+ lines is a bad sign.
Even if it's well-structured, why force your idea of how much I have to scroll?
And why making git diff overviews less useful? (glance over filenames)
I've never heard of an approach like this, how did you settle on 42? I'd be very interested to see an example if you have some code hosted somewhere?
My initial reaction is 42 is too short and would encourage terse non-descriptive naming and be a pain to deal with long strings.
I find it’s helpful because beating any structure beyond maybe 5 levels deep is painful, so I am forced to refactor.
Names aren’t so much of an issue because of the single-file-per-repo and 150-line-target principles:
If your module only consists of 150 lines, there’s just not enough in your namespace to need long names. Essentially, you only ever work within a small, isolated piece of a huge flat namespace.
Long names are necessitated by the huge, deep API surface that the filesystem provides.
A while ago I was prepping for programming interviews and thought it would be fun to make some videos demonstrating some programming concepts [1] due to my perception that there was a lack of material linking code with visualization/conceptual understanding. It wasn't long, though, before I stumbled upon a website [2] that had many videos that did just that, so I got a bit discouraged and gave up.
Around this time, I was also watching videos on algorithms [3]. After watching many videos where the professors give very thoughtful hand-drawn examples, I became convinced that the hard part is truly understanding the algorithm/data structure and that the code is the "easy" part. Maybe that's just my bias talking because I was a computer science major, though.
I still think that documenting a codebase with GIFs and video demonstrations is really useful. I get kind of sad when I visit a github repo and there are none of these because it can be hard to get a sense for what the code does (even a screenshot goes a really long way). For example, I think [4] did a really good job and I modeled a recent project's github README after it.
- [1] https://youtu.be/Z35sLFyLBek
- [2] https://www.geeksforgeeks.org/fundamentals-of-algorithms/
- [3] https://ocw.mit.edu/courses/electrical-engineering-and-compu...
It would be cool if it made use of the GitHub API to get the data. Doing so should be possible, the GitHub API gives access to a lot of data about repositories. For example, here is a static page I made that pulls some data from the GitHub API so that I don’t have to keep the HTML data for the table at the bottom of the page manually updated with what repositories exist in the GH org it belongs to and thanks to that I also have the number of open issues right on the page: https://dcp-solved-with-rust.github.io/