Completely agree. But the tools don't make this very easy.<p>Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and if I wanted to discuss a piece of code with my CS lab partners, I couldn't just share a link.<p>A friend felt the same pain but then went to work at Google for a bit. At Google, they have some pretty amazing code reading/searching tools (see <a href="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43835.pdf" rel="nofollow">https://static.googleusercontent.com/media/research.google.c...</a>), and these tools helped Google build a culture of thoroughly reading and reviewing code. The causality is bidirectional, but having good tools certainly played a role in Google's success.<p>That friend and I ended up building a product, Sourcegraph, initially for ourselves to make code reading easier. We've now built a successful business out of it with the help of an amazing team. Here it is pulling in the OpenBSD sources: <a href="https://sourcegraph.com/github.com/openbsd/src/-/blob/lib/libutil/bcrypt_pbkdf.c?q=bcrypt_pbkdf#L98-98:13" rel="nofollow">https://sourcegraph.com/github.com/openbsd/src/-/blob/lib/li...</a>. Sourcegraph has advanced features for several languages; see <a href="https://sourcegraph.com/github.com/mholt/caddy/-/blob/caddyhttp/httpserver/https.go#L22:23$references" rel="nofollow">https://sourcegraph.com/github.com/mholt/caddy/-/blob/caddyh...</a>, for example. If you love to read code (or want to), we hope you'll love our product. Email me if you have any feedback/requests.
I love this idea in part because it's the very opposite of the way I tend to work, which is to drive very hard to get a surface understanding of a thing in order to make a very targeted change. I learn lots along the way with this approach, but don't often get the deep, wholistic understanding of existing systems that only comes with repeated exposure over a long time.<p>Some kinds of understanding involve a no shortcuts grind. That sort of a grind is a big commitment though.
I've been using Typing.io as a platform for reading source code (working my way through Gitlab now) and practicing typing with the right fingers. I have a few minor bad habits to correct, and I want to familiarize myself with the codebase, it's a good way to warm up for the day.
I've fallen into doing something similar. I read the mailing lists regularly try to look over the source for something that gets a proposed patch. Because OpenBSD boils down their software to the essentials and tries to make their APIs impossible to misuse I find it pretty easy reading even though I'm not very experienced with C.
Here's the latest daily chat transcript, from Jun 9th: The topic was OpenBSD nc(1) and libtls, but it wandered over to pledge(2) and other code fixes from new participants eager to contribute.<p><a href="https://junk.tintagel.pl/openbsd-daily-nc.txt" rel="nofollow">https://junk.tintagel.pl/openbsd-daily-nc.txt</a>
Anyone have a good exemplar React application for this purpose? I'm building small experimental stuff and now I need to level up and see how real applications are being built.
I read the emacs lisp source code in site-lisp/ every day. The goal is to understand one file about a week or so. It has made my emacs and lisp knowledge better, and made me aware of several nice emacs features (align-regexp, for example).
This is fantastic! I've recently decided to begin reading web browser source code, even though I understand very little of it at the moment.<p>For now, what's been fun is to load up the same file in both Chromium and Firefox source, and compare the two and how both browsers work.<p>Chromium source: <a href="https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/" rel="nofollow">https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...</a><p>Firefox source: <a href="https://dxr.mozilla.org/mozilla-central/source/" rel="nofollow">https://dxr.mozilla.org/mozilla-central/source/</a>
How about using a static security source code analyzer and going through all findings? The very good ones, the commercial ones, are free to use for open source projects. That would be real benefit to the project I think.
This is a smart thing to do! I might do it eventually... not right now though, because of <insert whatever reason you can think of here>, and stuff, you know.