251–260 of 294 posts
I think musl libc [1] has good quality code. If anything their build system is great. It makes the code much easier to navigate. [1] https://www.musl-libc.org
https://git.musl-libc.org/cgit/musl/tree/src/string/strcspn.... https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.... ah yes, good quality code
When we take the language into consideration, unwound like to mention Redis. Often codebases written in C are a a mess to understand, a mess to read. The Redis Source Code is understandable even without deep knowledge of C
Yep. I was going to say Redis and SQLite. Both are really well commented. They almost read like a manual.
Very well organized code and it feels like they got the project off the ground, fixed bugs for a few months, and now have largely trailed off from maintaining it largely because it just works (I use it) which lends some credibility to their coding style. Of course, I'd like to see the project evolve conceptually, but, right now it does what it says it does reliably for a project that hasn't even cut a single release.
NetBSD. Why? I was able to do substantial changes to the kernel when I was a teenager (late 90s), mostly on my first try. There was no giant wall of abstraction I had to climb over or some huge swath of mutually interacting code I had to comprehend. There was also nothing that required fancy code navigation and the creation of something like the ctags database in order to find out what on earth was happening. No acti…
Ah, I see you've also looked at the Linux kernel code.
I was going to say the GNU version of /bin/false and /bin/true, but I actually took a look at the source and it is terrible.
I'm surprised no one has mentioned the Linux Kernel! https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... It is quite clean when you consider the task that it accomplishes. Being able to compile across multiple architectures/endian-ness,32/64-bit/scale up/down from server/desktop/router/phone while accepting contributions from thousands of people..
(Sadly, most of those good kernel books were written in the 90's and early 2000's. I don't know if there are any recent kernel hacking books.)
I hold the source code of Go standard library & base distribution (i.e. compiler, etc.) in very high regard. Especially the standard library is, in my opinion, stunningly easy to read, explore and understand, while at the same time being well thought through, easy to use (great and astonishingly well documented APIs), of very good performance, and with huge amounts of (also well readable!) tests. The compiler (includ…
For me, code readability is such a high value that, on these grounds alone, I oppose the introduction of generics and hope the current proposals ultimately fail.
OpenBSD and Co. (OpenSSH, etc.) * https://cvsweb.openbsd.org/src/ * https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ * https://www.libressl.org/ * https://cvsweb.openbsd.org/src/usr.sbin/ntpd/
There's a lot to admire in OpenBSD but sometimes the peripheral tools they deliver don't work well. The example I know best is OpenNTPD (last link in your comment). It has a bunch of problems, including relatively poor clock discipline compared to other NTP implementations. And it doesn't even try to handle leap seconds. That causes problems on the machine itself which may or may not matter to you, but it's catastrop…
Going to throw Elixir Lang into the mix. - The tooling is excellent. - The code is well-documented and readable. - The core team committed to never needing to introduce breaking changes. The Elixir community tends to produce work that is actually considered "Done". An elixir package is not stale when it hasn't seen a commit in a few months. Instead, the feeling is: "It's feature complete and only needs maintenance fr…
Is this why Elixir seems to have many different ways of doing the same thing though?