Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What's the best source code you've read?
330 points by KennyFromIT 24 days ago | hide | past | favorite | 261 comments
What did you read that was really eye opening in some way?

Please provide a link, if possible.




I was responsible for the Turbo C (later Borland C/C++) run-time library in the late 80s and early 90s.

Tanj Bennett created our original 8087 floating point emulator. It was real mode, 16-bit code, that kept an 80-bit float in five 16-bit CPU registers as a working value during its internal math calculations. If you ever coded for the PC you will appreciate just how precious register space was on the 8086/8088.

It's been a few decades and my memory is fuzzy but I don't recall any critical places where the registers had to be saved and restored. He choose math algorithms and code paths specifically to keep all five live at all times. Tanj's code flowed with an economy of motion that brought to mind the artistic performance of a professional dance troupe. I did not have the math skill and could not have ever created it as he had. It brought me genuine pleasure just to read his code.

Eventually, it came time to port it to 32-bits (real and protected modes.) I wrote new exception handlers and replaced the instruction-decode logic with a nice table-driven scheme but did not touch the core math library. It still ran in 16-bits under the hood exactly as Tanj designed it.

Tanj, if you happen to see this, I have fond memories of your emulator. It was beautiful.


Hi David, thanks for the kind words. I still have the source for that I think, it was written around 1984 originally for a project of my own, then sold to Logitech, Zorland, and Borland (before I went to work for Borland). The Borland one was probably tweaked a bit - like you my memory does not include details.

There were 7 registers to play with. AX, BX, CX, DX, SI, DI, and occasionally BP. MS-DOS had no rules about frame pointer although later Borland would prefer it was kept to a standard use so that exceptions can be handled.

It would have run faster in 32 bit. Many fewer cross products for multiply and faster convergence for division and sqrt, plus just fewer registers needed. But updating the entry and exit code may have been the largest win. By the mid 1990s the FPU was moving onto the CPU chips even at the low end so the main goal would have been stability and backwards compatibility.

I wrote assembly code for many machines before and after that. In the early days such careful juggling of registers was routine. I generally wrote my algorithms in Pascal (later in Modula or Ada and by Borland days, in C++) and then hand compiled down to assembly. That separation of algorithm and coding stopped it getting too tangled.

Thanks for the shout out! These days I write System Verilog (algorithms modelled with C++) for hardware projects, and Julia for the pure software.


Tanj, these are all the most excellent reasons why we were proud to have you as part of our Borland team. Software craftsmanship.


I have shared this with Tanj. I had the privilege to work with him in Microsoft!


Awesome!!

Would it be possible to release this bit of the library, if not the whole thing (for any definition you like of "whole thing") à la Movie Maker (https://twitter.com/foone/status/1511808848729804803)?

More specifically there are two components to this question - it being OK for the code to be released, and the code itself being available to be released :). I'm specifically asking after the former; if noone knows where the code actually is right now, well, it can be dug out later.


Nice idea, but I honestly don't think it has much value for study. It was a solution to a problem which is no longer important, and what impressed David (and was fun for me) was implementing it under constraints (8086) that are no longer relevant. I would vote for some of the other stuff mentioned by others, like TeX as an example of mastery of both the application requirements with beautiful algorithms and inspirational documentation, PostgreSQL as a thriving large system with brilliant modularization that has enabled research, or LLVM as a pinnacle of code generation which has enabled a golden era of language and hardware design over the last 20 years.


Borland made some copies of Turbo C available for free. E.g. https://cc.embarcadero.com/item/26014

Some sites probably also have versions for download without the registration requirement


You just have to love HN, thank you!


I would have loved to read that code!


Nobody has mentioned Knuth’s corpus of work in Pascal-Web for the TeX ecosystem. This is code written for an era where there wasn’t an ecosystem of libraries for common tasks and even things like being able to access a file in random access order couldn’t be counted on. Even 7-bit ASCII couldn’t be counted on as a given (EBCDIC-based IBM mainframes were a significant element of the computing landscape still).

Against all that, Knuth wrote code that could be ported to other systems (I first used TeX on an IBM mainframe running VM/CMS, then later on a VAX minicomputer running VMS, then on a PC with DOS, PC with OS/2, PC with Windows and now a Mac with OS X/MacOS. His presentation of code and internal documentation intermingled is something which I could see still being useful now, although sadly, literate programming seems all but dead now. I still go back to Knuth’s code to understand how to solve some problems on occasion even though it’s about 30 years since I last wrote a line of Pascal.


> although sadly, literate programming seems all but dead now

It seems alive and well in the data-science community to me. Look at jupyter notebooks if you aren't aware of what I am talking about.


You mean a system with heavy dependence on global state yet allowing for arbitrary command/code chunk execution order?

Where significant parts of the display remain out of sync with said global state?


It’s not really literate programming. It’s just editable/executable code intertwined with text. There’s no tangle and weave, or code reuse.



The same thing. I don’t see chunk reuse, nor the ability to generate standalone documentation or export the code to files.

Have you seen actual literate programming documents? The Noweb tool’s page has examples.


The imports are chunk reuse. Each notebook is an es6 module you can import from any npm package.json You don't need to export it as documentation, it is executable documentation which is better, though you can print it if you want. The footer backs up the source to github

Your stuck on Knuth's definition of literate programming but this is better than that


Sounds like nbdev which indeed exports code and documentation from a single notebook, plus unit tests for external execution.


Back in the day I worked quite a bit with Knuth's early SAIL (an extended Algol on the PDP-10) implementation of Metafont. They could have used some of the documentation the later WEB versions had as he tended to get tricky with squeezing everything out of the 36-bit words (which I was porting to a 32-bit word machine). But the code was an education and a joy to read well before he polished it for publication.


I’ve heard some wild things about the old SAIL stuff. I never had the chance to encounter it though. I got on the TeX train in 1985¹ with TeX82/MF84. AMS/TUG still were using the am* fonts for their publications.

1. My very first exposure was DEK’s article “TeX and Metafont” in a copy of Dr Dobb’s Journal that was part of a trove my brothers got a hold of—and then in 1984 seeing someone in the IIT computer lab paging through a copy of The TeXbook, so when I found out that UIC had just installed TeX on their mainframe, I was one of the first people to use it there.


With the sorry state of latex engine error messages and the version number still approximating pi, e, something, it is no longer an ideal to me. It represents stagnation. Being bug-free may be good, but at some point feature development is needed. (I know TeX and LaTeX are not the same)


There are some serious legacy issues with the LaTeX ecosystem. The lack of being able to version individual package dependencies for a document is a huge one. You’re at the mercy of lots of independent packages which often have complex webs of interdependency.

Probably the biggest mistake was the choice to abandon the idea of having a LaTeX 3 version with its implicit breaking of backwards compatibility. Backwards compatibility means that there’s a tangle of fragility that only grows with time which is part of why the error messages are so frequently bad. Changes are a fraught proposition. This is part of what inspired my decision to start work on finl.


Best of luck


I think LSP language server protocol and literate programming are a match made in heaven.

A simple syntax like noweb and a LSP dispatcher which only handles the noweb syntax elements and dispatches both text and code chunks to respective back ends; the LP LSP Server tangles the code chunks and presents the tangled code to the code specific LSP servers and does the mapping forth and back of the position-in-nw vs position-in-$code while passing all other communication through.

especially now that we have DAP something like this would really make sense, wouldn't it?


Speaking anecdotally, I have nothing but issues with LSP. It's a pain to use, a pain to configure, gives sub-par results and is usually wraps with extra "features" that change how code gets edited between different languages (I know this is less LSP's fault).

Not to dismiss the mountain of work people have put into it, but it feels very hacked together and clunky rather than a shining achievement.


Case in point, Microsoft develops an editor (VSCode) and LSP so that N*M language integrations wouldn't be necessary. But in the development of their language (TypeScript), LSP support is not a priority (in part because LSP is inadequate in its current form): https://github.com/microsoft/TypeScript/issues/39459


> We're working on this, albeit slowly. tsserver's implementation predates LSP so it's nontrivial work to move forward in a way that doesn't adversely affect old clients or result in code duplication.


Good to hear you're still committed. By "not a priority" I mean we have been waiting since this was published back in 2016: "[LSP] also means any developer can have a consistent editing experience for their favorite programming language on any tool – even if that tool isn’t VS Code." https://code.visualstudio.com/blogs/2016/06/27/common-langua...

The original bug against Typescript was opened in 2016 as well: https://github.com/microsoft/TypeScript/issues/11274


Note I merely quoted from the above Github ticket. :)


I see. In that case, possibly replace "you" with "they" in my reply.


I've been writing a literate multi-file program in Go and Copilot has been partially compensating for the lack of tooling support, especially since Copilot can infer from prose.

I intend to make a post about my experience.


TeX was beautiful. Both the algorithms (it was a masterwork on typesetting, still a good reference for anyone doing text layout) and the book.


I second the nomination. I too have found the TeX Book to be very readable.


Pedantic note, which I'm writing just in case anyone misunderstands your recommendation:

"The TeXbook" is the user manual for TeX. It is not the same thing as the book containing the (literate-program) source code for TeX, which is called "TeX: the program".

(Both are excellent, but in quite different ways, and someone looking for interesting code to read would likely be disappointed by the TeXbook, which doesn't contain that.)


You’re right! I had to go pull my copy off the shelf and check, but it really is TeX: The Program.


Make sure to check out the dedication!


Postgres code is very good, redis as well. Some of the core parts of Linux also totally worth learning from.

I also remember how Qt UI code and docs were a revelation after the nightmare of win32 and related frameworks.

Bellard's original Tinycc was very entertaining and took a while to digest.

Most old and well-maintained projects are worth learning from.

Apart from some local tips and tricks what is more important is understanding that there's nothing special about other people's code.


Seconding redis, and noting that the original redis source code is _also_ an interesting read and demonstrates how approachable well-written tcl is, even for those entirely unfamiliar with it as a language: https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...


Which part of linux core? I’ve been wanting to but I don’t know how/where to start


I enjoyed reading the VFS layer down into the NFS client file ops and then the RPCs created from them. (skip the RPC state machine)

An easier entry point might be the ethtool_ops in an earlier Intel network driver like e1000.


Redis, yes, even if you do not like/know C, that code is so clean that is readable/understandable by most programmers.


Qts documentation is a minefield but their source code is really nice and easy to read.


+1 for redis, first code I read that felt like artisan craftsmanship, approaching art.


One of the most surprisingly clear code bases is LLVM. It’s an old complex beast, yet it’s organized beautifully.

I mean, it has a lot of essential complexity but little accidental complexity.

That’s usually what I strive for when coding. Complexity is sometimes unavoidable, that’s fine, that’s why it’s essential. However, avoidable complexity should be… well… avoided.


> a lot of essential complexity but little accidental complexity

Nice one. I'll copy that.


You might be interested in reading the paper, No Silver Bullet, in which Fred Brooks coined these terms:

http://worrydream.com/refs/Brooks-NoSilverBullet.pdf


Didn't he copy them from Aristotle?


The idea of essence and accident comes from Aristotle, while essential and accidental complexity is new by Brooks.


That's from "The mythical man-month". Old, and some parts are obsolete, but still worth a read as it does have a bunch of good insights.


I have not read it in a while but it would be interesting to debate what essays are no longer relevant. I'll be grabbing it off the shelf next to my original copy of the Byte issue on C mentioned yesterday and having a look for expired relevancy.


There are some sections about physical copies of documentation and managing the logistics of that when I read it.


Reminds me of a book I picked up about twenty years ago called "Testing Computer Software". I think it must have been written in the 80s, because instead of having a bug database, it talked about filling out a hardcopy form describing the issue and dropping it off at the programming department. I reckon you'd want to do it in duplicate on carbon paper, just so you can keep it in your own filing cabinet.


wouldn't wikis be good the contemporary successors of that section? it's about documentation being disconnected from code, about co-evolving and providing both in an economical way, in contrast to being inefficient or even ineffective in documenting technology.


I haven't read it in a while either, but from memory the team organization of one "architect" and a bunch of implementers seems obsolete, for example.


Imho it's more relevant than ever, with the influx of cheap offshore remote developers


This is what I came here to say. it and clang are both good source code.


Really? Go and read the assembly parser and get back to me.


I haven’t read all of it, but the Principia source code has a comprehensive units system and makes effective use of Unicode: https://github.com/mockingbirdnest/Principia/

https://github.com/mockingbirdnest/Principia/blob/master/ast... is a decent example of both:

    // We compute the mean rate (slope) of the mean anomaly M(t), the mean
    // argument of latitude u(t), and the longitude of the ascending node Ω(t).
    …
    Product<Angle, Square<Time>> ʃ_Mt_dt;
    Product<Angle, Square<Time>> ʃ_ut_dt;
    Product<Angle, Square<Time>> ʃ_Ωt_dt;
    …
    ʃ_Mt_dt += (Mt + previous_Mt) / 2 * dt;
    ʃ_ut_dt += (ut + previous_ut) / 2 * dt;
    ʃ_Ωt_dt += (Ωt + previous_Ωt) / 2 * dt;
    …
    anomalistic_period_ = 2 * π * Radian * Δt³ / (12 * ʃ_Mt_dt);
    nodal_period_ = 2 * π * Radian * Δt³ / (12 * ʃ_ut_dt);
    nodal_precession_ = 12 * ʃ_Ωt_dt / Δt³;
The advantages are concise notation plus compile–time guarantees that the units work out. I don’t care much for C# in general (or C++ for that matter), but I like the results here.

Sounding out the Greek names occasionally used as release names is always fun too.


lovely. it's 2022 and I see unknown-glyph-boxes on my up to date smartphone...

I love the use of mathematical glyphs in math code, too, much more readable, _if_ it's readable.

sigh.


The problem is (apparently) no monospace version of the /ʃ/ character, which renders fine in non-monospaced fonts (on Android).


yes in this font I can indeed see it on the same device :-D


I guess you’ll have to install an extra font or two.


Using Unicode symbols wisely in mathematical code is a godsend. I regularly use Julia, which favors this style, and find that this feature improves the readability of code enormously.


How do you then type these characters? google, copy, paste? Or is there a better workflow?


Julia mode for Emacs, Vim, and VSCode lets you to use LaTeX-like sequences: write \pm, press <TAB>, and you get ±

Of course, this only works if your editor supports this and you are using a language similar to Julia. But there are two more general methods that are applicable everywhere. The first was mentioned by db48x: I have customized my Xmodmap file so that greek letters and a few typographic characters I use often can be typed using AltGr combinations. (Unfortunately, this is much more complicated if you use Windows.)

Secondly, I heavily use Espanso [1], so that I can easily type complicated letters/sequences (e.g., my email address) for which it would be too overkill to assign an AltGr keybinding.

Finally, in Emacs and Kitty (my terminal emulator) there is a keybinding that asks for the name of an Unicode symbol and enters it. (In Emacs it's C-x 8 <Enter>, in Kitty Shift+Ctrl+u.)

From the point of view of my workflow, the problem of quickly typing Unicode characters is completely solved.

[1] https://espanso.org/


Two ways: keyboard layout and editor support.

Your OS keyboard layout, at least on Linux, can be customized to include any characters you type frequently. I haven’t gone very deep down this rabbit–hole, but I have turned on some options that make nice quotation marks (“‘«»’”), em–dashes (“–”), ellipses (“…”) and a number of other characters (“²³½⅓¼≠±÷∞×” and so on) readily available with a compose key. I also put arrows on the numberpad, of course (“↙↓↘←↔→↖↑↗⇙⇓⇘⇐⇔⇒⇖⇑⇗”). Very useful for talking about menu items, like File → Save As (it has actually startled people when I can type things like that fluently in conversation).

My editor of choice is Emacs, which has a built–in way to select characters by name. Typing `C-x 8 <RET>` prompts for a character name, with fuzzy searching and autocompletion. It also recently gained a similar facility for Emoji, which is more focused around the visual appearance. `C-x 8 e e` opens it. `C-x 8 e s` lets you search by name.

Between your keyboard layout and your editor’s search capabilities and custom keybindings you can do anything.


Some years back I wrote myself a small SublimeText extension to to pick & insert my favorite math characters but nowadays I prefer using rofimoji[0] because it is application-independent.

[0]: https://github.com/fdw/rofimoji


C#?


Much of it is in C# so that it can be run inside KSP.


> C++ 89.1% > C# 5.4%

It looks like it's mostly just a C# wrapper around the C++?


It’s not the best, far from it, but it was fascinating to me so I will share.

I used to work for a large newspaper. Engineering wasn’t the focus of the business, it was only a means to an end, it was just something they needed to have a competitive website. As a result, the churn rate was very high. But more interesting there was also a very high return rate. Engineers would come and go and return and leave again all the time.

As a result, the code base was a path work of various engineers with various skill level, different directions by different heads of engineering, repurposed old projects, legacy code and last minute additions by urgent request from the editors, among others.

The part I was most familiar with was what I can only describe as a sort of next.js but unlike it, it wasn’t planned or designed but rather it sort of grew organically over the years.

The fascinating thing to me was precisely this phenomenon. Some projects have a clear design and purpose and are built so from the start. Sort of like a building or a mechanical clock.

Others just evolve over time, they change, mutate, evolve, incorporate other bits. More like a biological organism or perhaps nature taking back a derelict settlement.

At first as you can imagine it was difficult to wrap my head around it. But in time, I started to see the beauty in it. It had historical bits. There was code written in 2010 that ran in 2020. Others you could tell little habits of the writer. Not everything gets stamped out by the linter. There was this guy who wrote “class ClassName extends React[“Component”]” - I have no idea why but I would run into code written by him and immediately recognise, ah yes, that’s that guy.

It’s certainly not an example of a good code base, but to me was interesting being able to see the code as a living organism with a history and fingerprints of it’s creators rather than a well designed machine.


The book "A Deepness in the Sky" features people living on an ship whose operating system is thousands of years old. One of the main characters is considered a software archaeologist of sorts - he's an engineer, but in a sense also a historical researcher.

I can't emphasize enough that this notion is only a side point in the story and not a main aspect of the plot, sadly, so I wouldn't go reading it in hopes of hearing more. (Although it is a great book regardless.)

I have often considered trying to write a scifi novel centered around this idea because I find it so fascinating.


The "software archeologist" idea has lived rent free in my head ever since I read the novel nearly twenty years ago. It's an absolutely fascinating premise, one I can most definitely see being viable to grow into a fully-fledged novel. I would definitely read that.


We're half-way there already. I've been telling people that the volume of software written has exploded exponentially, and the real skill anyone in IT has now is not knowing how to use a piece of software on a computer, but simply knowing that a piece of software exists to solve a problem.

These days I work largely in a cloud / devops role, and I can't even begin to list everything that I ought to be using but can't because there aren't enough hours in the day to keep up with all of the new developments. That's within a single language, a single web framework, and a single cloud provider!

I see projects where architecture astronauts stitch together multiple clouds, multiple languages, and some random junk on-prem that was installed over a decade ago by someone who has passed away since then. Within the expected lifetime of such a system, you'll need a software archaeologist to figure it out!


DRMaciver wrote a novella about it. Programmer at large, it's called. Largely about cultural variation in gender and sex norms.

https://www.drmaciver.com/category/programmer-at-large/ (down)

https://archiveofourown.org/works/9233966/chapters/20941043


Interesting to note that you’re basically describing the concept of common law.


That actually is interesting to note. I hadn't thought of that.


I regularly describe my day job (which consists in reading a 10-year old, arcane & barely readable Spring code base) as me working as a software archeologist. :)


> I can't emphasize enough that this notion is only a side point in the story and not a main aspect of the plot

Is it sprinkled throughout the story, or a mostly uninterrupted block of text? As in: is there an easily findable chunk of the book one could read for that idea alone? If so and you could provide a few keywords or a direct quote, I’d be interested in grabbing the book to read that.


I just went and glanced over the text by searching a pdf for a few key terms - no, it's really just sprinkled. The idea doesn't get much attention and is mostly mentioned in passing.


There is the bit where the story of Pham’s youth is told. He was third son of a King on a medieval–tech world (one with ancient stories of flying machines and long–distance communication devices) when some traders from a distant world landed. To everyone’s surprise they were human, and had expected this world to have a much higher technology level when they arrived. Pham’s dad did some kind of deal where his son Pham was given to the traders as an apprentice; even Pham didn’t know the details. Pham spent the next 20 years or so living on the ship because he refused to use the suspended–animation system (too coffin–like). He learned use use the many layers of emulation to use older and older programs, and eventually learned even trivial details. For example, he learned that the epoch of the time system used by the traders wasn’t actually the date of the first moon landing, but was a couple of years after that. He even hypothesized that over the millennia, many ship’s captains would have installed back doors in the system that might now never be rediscovered (which turns out to be foreshadowing :).

One funny detail I remember is a throw–away line where someone rapidly keys in “a column of text”. If you’re paying attention you can combine that with names like Pham, Vinh, Nau, and Qung Ho, the rarity of the red–headed gene, and the descriptions of some traders from the far end of human space you can reconstruct how things went after Humanity reached the stars.


This is a natural development as the field matures. I've worked in codebases that had roots in the 1980s, and large chunks of code survived virtually unmodified from the 90s. I'm sure some here could tell stories of even older codebases.

Living codebases that have such old roots but have seen gradual maintenance and refactoring such that the whole thing didn't degenerate into spaghetti deserve a lot of respect in my opinion.


Sounds like the codebase really was a living thing in a sense


People here on HN have compared the evolution of large and old code base to the evolution of DNA before and I think it makes perfect sense: E.g., in both cases, complexity has grown organically over the years/millennia and logic tends to be spread out over dozens of files/genes; change one line of code/gene and suddenly it will impact lots of other things; et cetera.


i relate to this currently and that is a great way to think about it. thank you for posting this.


I will always have a soft spot in my heart for Django, the python web framework, even though I don’t use it anymore. https://www.djangoproject.com/

When I was still learning to code, I spent hours and hours and hours poking around the Django source code. In particular I was fascinated by the metaprogramming used in the Model and Query objects, and I ended up learning a ton about how Python works under the hood.


Please don't recommend django, its a dumpster fire in terms of code quality.

Opening random file on github: django.core.serializers.python https://github.com/django/django/blob/main/django/core/seria...

  - function name doesn't match pep8
  - name doesn't match its behavior
  - docstring is trying to explain what it does instead of proper function name, see 2
  - 60 line for cycle
    - what does d mean in for d in object_list? perhaps d as an object/instance/item? Good luck remembering that when you reach end of this for 60 lines later
    - using comments instead of functions
      - Handle M2M relations could be replaced with handle_m2m_relations(...)
      - Handle FK fields could be replaced with handle_fk_fields(...)
      - and so on ..
  - using/catching generic exceptions
  - using isinstance instead of proper polymorphism
  - **options
And I've seen way worse things inside django than this. Please don't recommend django. Please

https://github.com/django/django Django's codebase is a pleasure to read. The directory structure is intuitive to navigate, and test coverage is great.


Me but with Flask and its cohorts like Werkzeug. I always found the amount of security advisories with Django vs that to be something alarming. I might still use it once in a while for something like prototyping.

Python is easy to write but writing it "right", in a way that doesn't compromise performance, is a thing.


> Me but with Flask and its cohorts like Werkzeug. I always found the amount of security advisories with Django vs that to be something alarming.

At work, another team introduced automated CVE scanning to fulfill a contractual obligation to do so. When they asked me to implement this on my team's Django project, I said "well alright, as long as it doesn't constantly break the build because of some obscure false positive CVE".

Within a week, the CI job was broken because of 5 "CVE"s. 4 were false positives for our project and 1 was a configuration error by the other team.

Just to let you know to take "number of CVEs" with a large grain of salt.


You get CVE’s inside Django because it’s a large and widely used target, and because in Flask, FastAPI, etc. you end up implementing a lot more stuff yourself instead of using built in things. That doesn’t necessarily mean your code is more secure!


It ups your chances. I try and choose small, well-written libraries to work with in everything I do. Too many batteries included and they start to leak eventually.


I feel much the same about django rest framework


My favourite is SerenityOS: https://github.com/SerenityOS/serenity

Not only is the code itself structured much more pleasantly than I ever suspected possible in C++, huge parts of it were also recorded while they were being written (see https://www.youtube.com/c/AndreasKling) so you can see and hear the process that led to the final product.

Some of the code is quite gnarly, which is to be expected from a repo containing an entire operating system, containing everything from the kernel to a bespoke web browser.

However, as SerenityOS isn't trying to be a UNIX clone, its C++ oriented APIs are a nice breath of fresh air compared to the barebones C that Linux and friends use.


I will second this. I looked into implementing a traceroute utility for Serenity, and went in without any knowledge of the code. I haven't even watched any of the author's videos. But it was so well written that I was able to get a basic version running in a few hours.


Peter Norvig's spell checker: https://norvig.com/spell-correct.html


PAIP is easily one of my favourite programming books. It’s chapter after chapter of excellently presented programming. Each chapter takes you through a problem, a solution (typically multiple iterations and extensions) with detailed explanations of what’s happening (often with historical details). Also, it introduced me to many different tools I can use to solve programming problems.


All Norvig's code is nice to read and also often enlightening.


Nice example, note to do autocomplete with something neural based these days like https://text-generator.io or huggingface or spelling with neuspell etc

Peter did done great ground work here and as things transitioned to neural nets, also peter appears randomly in my Chromecast with some nice photos he took lol


His Lis.py is also wonderful.


Poul-Henning Kamp was on a FreeBSD podcast (~15 years ago) and did an approachable walkthrough of the performance considerations he made when he created varnish. It stoked some serious curiosity in me, i was working on a system that heavily cached IO in userspace (and paid LOTS of money to do so - we're talking 100s of nodes) and here he was saying things like (i'm paraphrasing here) it's pretty dumb to cache your data from disk in userspace. One thing led to another and i scored a nice bonus that year. By the end of that year i had learned about (and put to good use) techniques like IRQ pinning and of course understanding the caching tunables in the linux VFS layer. I can't find the podcast to link to but this document is pretty much on the money for what i remember hearing https://varnish-cache.org/docs/trunk/phk/notes.html

Another one is the Postfix codebase by Wietse Venema. It was notable because it's basically had the square root of 0 vulnerabilities despite being written in C and being one of, if not the most popularly deployed MTAs in the world (so basically a constant target for hack attempts - contemporary products like Exchange were basically a laughing stock for vulns in that time period). Anyway, the architecture of that codebase is bordering on beautiful. It's a total goldmine.

Bonus - a popular code base that made my eyes bleed, nginx. I think it's basically been re-written today but the earliest versions of it were horrible to read. It was fast back then but it was like some sick twisted joke of how to write code. This is not to take away from whoever created it, they still created a monumental shockwave when they released nginx, it was far more performant that anything else.


Was this [0] the podcast by chance? Seems to fit the bill.

[0]: http://bsdtalk.blogspot.com/2006/10/bsdtalk072-interview-wit...


That’s the one I’m sure


I had quite some pleasure working with the Source Engine gameplay code. (Some 10 years ago now)

https://github.com/ValveSoftware/source-sdk-2013

It is not that the quality of the code is high, but just that it is well organized, and everything seems like it was written by a beginner. That makes it wonderfully easy to read and follow the logic.

Since have played around with the Source Engine, I follow the KISS principle with coding with high priority. Rarely trying to be clever, or try to over-do abstractions.


> and everything seems like it was written by a beginner.

So many developers are afraid of their code being described that way. People are weird.

I'm starting to have the opinion that you shouldn't give software architects the title of software architect because they'll feel as if they're not doing their job if things are simple rather than architecty.

I say that because a software architect is really just a developer with broad scope, but I suspect most of the software architects I know would be offended by that description (I myself hold the title software architect).


I've never seen C code as clear and well documented as tcl. E.g. https://github.com/tcltk/tcl/blob/main/generic/tclUtil.c, though more examples in that project are not hard to find.


SQLite originates from the same author and is hosted in fossy which is similarly concise and beautiful.


Kind of ironic given how bad TCL itself is. Reminds me a bit of the CMake source code which is nicely written and easy to follow but... it's CMake.


There's also https://github.com/servusdei2018/GladiatorPits-MUD, which is a really well-written program dating back to 2000.


Maybe not revolutionary, but I think this article about static binary translation is a great introduction to the topic:

http://www.gtoal.com/sbt/

(see also the "Virtual Machines" book by Smith and Nair, ISBN-13 978-1558609105, if you are interested in this topic).

I can also recommend John Lions' "Commentary on the Sixth Edition Unix Operating System" - https://warsus.github.io/lions-/, Douglas Comer's Xinu (https://xinu.cs.purdue.edu) as well as Niklaus Wirth's "Compiler Construction" (https://people.inf.ethz.ch/wirth/CompilerConstruction/Compil...) and Project Oberon (http://www.projectoberon.com).


On the same note, the original Atmel8/16 chip datasheet. It made me fall in love with electronics


Well, eye opening was the C++ source code I was able to work with at a previous company, they were an automotive HMI developer company. They had really strict and well planned code structure that just hit a chord with me.

Can't provide source though on that one, as it's a propietary engine. Recently I've enjoyed reading the source code to Sokol, lot's of really good decisions there and I love the minimal C -style structure:

https://github.com/floooh/sokol


Nix source code is also a pleasure to read through. I was surprised that c++ could be so beautiful and well written.


C++ gives you an enormous amount of rope to hang yourself with, but it’s also an highly expressive language.


Nix doesn't use most of C++ features though. It's just the way project was organized and code was formatted that it looked beautiful and easy to skim through.


Contrarian answer: Conway's Game of Life in Dyalog APL https://www.youtube.com/watch?v=a9xAKttWgP4

It feels like the logical end state of "clever" code, for better or for worse. Or, alternatively, what happens when a standard library is gigantic but each keyword is 1-2 characters.


I also came here to mention this video. Watching the solution emerge line-by-line is a profound experience, and highly revelatory towards the kind of iterative problem-solving workflow possible in the Iversonian languages.

In the same vein, John Scholes' collection of APL code in the Dfns workspace[0] is positively wonderful to read through. I think it's probably one of the finest repositories of annotated code ever assembled.

[0]: http://dfns.dyalog.com/


my favorite of his videos is the sudoku solver: https://www.youtube.com/watch?v=DmT80OseAGs


I thought I wrote good Perl code until I read the Perl core modules. Like night and day.

Busybox and uClibc are great examples of efficient C code. I submitted a feature, and they basically rewrote it to be less crap, and that taught me a ton.

Hard to know what good Python code is. Everyone seems to use some framework that fundamentally changes how you write apps. "best source code" is probably just what's best for that specific kind of work.


> I thought I wrote good Perl code until I read the Perl core modules. Like night and day.

For some reason the 2nd and subsequent editions of the O'Reilly Perl book completely altered the layout and presentation that Larry Wall had set up. The first edition of Programming Perl is the most *lucid* programming book I've ever read.


> the Perl core modules

Likewise I've head good things about the Python standard library; I suspect this works for many languages.


The stdlib is pretty impressive because you see stuff that at first glance looks like there's an obvious simpler way, but then notice the edge case their way handles or the extra thing it enables, and it's clear that it's all been polished over time.


Not a single code-base, but The Architecture of Open Source Application books are worth a look to help get started reading various sources: https://aosabook.org


Not exactly source code, but the https://frinklang.org/frinkdata/units.txt is the most fascinating configuration file I've ever read. It is also the only one that I occasionally re-read just to enjoy the commentary on the standards organizations that are responsible for some of the complexity.


This is pure brilliance. The depth of reasearch they went to for some of the units is mind-boggling

--- start quote ---

    /*  From Department of the Army's authoritative study: "Effects of
        Nuclear Weapons", footnote 3 to section 1.45, available at:
        http://www.fourmilab.ch/etexts/www/effects/

       "The majority of the experimental and theoretical values of the
       explosive energy released by TNT range from 900 to 1,100 calories per
       gram.  At one time, there was some uncertainty as to whether the term
       "kiloton" of TNT referred to a short kiloton (2 x 10^6 pounds), a
       metric kiloton (2.205 x 10^6 pounds), or a long kiloton (2.24 x 10^6
       pounds).  In order to avoid ambiguity, it was agreed that the term
       "kiloton" would refer to the release of 10^12 calories of explosive
       energy.  This is equivalent to 1 short kiloton of TNT if the energy
       release is 1,102 calories per gram or to 1 long kiloton if the energy
       is 984 calories per gram of TNT."

       So, evidently they don't quite specify which ton is required...
--- end quote ---

And it goes on



I like the TypeScript compiler source (in TypeScript.) It's clean, easy on the eyes with well placed white space and just the right amount of comments.

https://github.com/microsoft/TypeScript/blob/main/src/compil...


It's got more regular expressions in it and I feel like any self-respecting compiler should have.


And the type checker is a single 45k line file! https://github.com/microsoft/TypeScript/blob/main/src/compil...


Surpised no one has mentioned the Nethack source, small codebase going on close to 40 years.

https://github.com/NetHack/NetHack/tree/NetHack-3.7/src


Sorry but I just can't see the beauty in it. Most files are arbitrarily named, without an abstract or overview. Few functions have comments, variables names are inconsistent or abbreviated to obfuscation level. Most code seems printf hackery to account for singular-plural, male-female, human-monster variations of the messages shown to the player. Not particularly easy nor gratifying to read.


Go up a level.


Yeah, was going to post Nethack if no one else had. It’s so well written, I think even people who’ve never seen C before could understand what was going on.


Apple's Swift source looks nice[0]. So does Darwin[1].

They have done a lot of work on structure and documentation, since the docs are auto-generated.

I have taken a lot of inspiration from them.

The Adobe APIs[2] were also excellent, but I'm not sure they are open for browsing, anymore.

[0] https://github.com/apple/swift

[1] https://github.com/apple/darwin-xnu

[2] https://developer.adobe.com/photoshop/api/


I quite like the FreeBSD src tree, as it comprises both the system kernel as well as the userland applications. The folders are organized similarly to the OS file system hierarchy, which I find helpful for navigating the source tree. I found it accessible to slowly learn how various parts of the OS work under the hood and compound my knowledge faster due to less context shifting, since it’s self-contained in one source tree.

https://github.com/freebsd/freebsd-src


Tangentially related, I found The Design and Implementation of the 4.4 BSD Operating System fascinating back in the day. I don't know how well it holds up now (or more importantly how relevant it is) but it was genuinely interesting, especially as I was using FreeBSD at the time.

https://dl.acm.org/doi/10.5555/231070


I have a soft spot for Musl libc just for how clear it is considering it's one of the most widely used libraries in containers and has to perform well in the real world.

https://musl.libc.org/


This is the first thing that came to my mind as well.

I've said on here before, it takes real talent to write code which is this legible while still being small and efficient.


Maybe I've just been exclusively working on really boring stuff, but there are no examples that particularly come to mind.

There are programs and programmers that impress me, and once in a while I'll come across an interesting algorithm, but I can't really think of any code that is anything more than just code.

It's either too simple to do anything I'm interested in, too full of ugly hacks like most large programs, or deals with math and algorithms way above my understanding, to the point where I probably haven't even tried to read it.

Some of most memorable bits or code for me are the examples for frameworks and libraries, but those are more impressive for the code that isn't there, rather than the code that is.

I love declarative work(Not so much pure functional, but things like CSS and CAD constraints where a solver figures out how to make your intent happen) but again, that's notable for the code that isn't there.

I also really like hardware workarounds. It's so cool to be able to have software that runs fine on bad hardware. It's not that common, but occasionally you can pull it off in a reliable way that really is just as effective as using better hardware. Seeing pure code replace hardware is kind of like a further development of replacing mechanical stuff with solid state chips.

I really just don't care about code itself very much. I don't want to write bad code, but I only care about good code in as much as it will actually benefit the project. Once it's good enough, features or architecture improvements or unit tests or something might be more important, and interesting or clever code might bring the project down.

If I'm reading your code, I'm probably either adding to it and complaining that it doesn't have an API hook already there, or fixing a bug.

If I'm using but not reading your code I'm probably happily assuming it's great, if it's a popular trusted thing.


A few that come to mind..

Hand-written compiler for WebAssembly Text format to binary - https://raw.githubusercontent.com/stagas/wat-compiler/main/s...

Gameboy emulator implemented in C, that also runs in the browser - https://github.com/binji/binjgb

QuickJS Javascript Engine - https://github.com/bellard/quickjs

The TypeScript language and compiler - https://github.com/microsoft/TypeScript


The Racket implementation for protocol buffers. The generated code is just an S-Expified version of protobuf source files, all macros which generate actual protobuf implementation at runtime lol. I don't know why I was surprised.

https://docs.racket-lang.org/generator/index.html

Can't find source code online. I browsed the code in emacs with racket-xp-mode go to definition after installing it via raco pkg install. Could probably use DrRacket instead of emacs/racket-xp-mode.

I had to read the source code to find out what the specific names of the proto creators, accessor, mutator functions would be.



The 8086 Assembly source code of the MikeOS operating system is remarkably readable and easy to understand for such low-level software http://mikeos.sourceforge.net


The early Go standard library (before it was hyper-optimized.)


I can't understate how valuable it is for a new language's stdlib to be so well written and therefore an excellent reference for style, design, performance, documentation etc. in your own code. Every time you need to lookup how something in the stdlib works, you get more exposure to what good code ought to look like.


They still try to document all the optimisations very thoroughly.


That's a fascinating observation. Do you think code inherently gets "worse" as it becomes more "optimised"?


Yes, as it becomes more complicated, catching more edge cases, it becomes less readable.

On the other hand, as the compiler improved, some parts of it became more readable (e.g not manually unrolling loops, avoiding manual inlining, introducing bit-manipulation functions into the library instead of repeating them everywhere).

Unfortunately, it's unavoidable — faster code is usually longer and more complicated.


If you plot difficulty to read against optimization, I'd expect to find a u-shape relation between the two.

When code is easy to read, it's easy to find and clean up redundant operations, which naturally makes it faster.

On the other end there's some optimizations that require dealing with lower abstraction levels and additional special cases.


cperciva writes easily the most approachable, understandable code I’ve ever come across, e.g.:

https://github.com/tarsnap/kivaloo


Thanks! I think kivaloo and spiped are probably the best quality code I've ever written.


Sure thing - I personally have ~zero use case for kivaloo, just came across it on here awhile ago and have basically been waiting for this Ask HN to pop up ever since:

https://news.ycombinator.com/item?id=24548103


The NetSurf web browser, and its modular parts (in C).

Quite simple and straightforward, and very modular. For a browser.

https://www.netsurf-browser.org/

https://source.netsurf-browser.org/


I see FreeBSD was mentioned in a different comment, but I’ll cast a vote for NetBSD.

The kernel abstractions that allow for portability make the code quite easy to read. Back in the day, I was able to write a file system from scratch by just reading the code of other file systems. The build system is also pretty amazing (allowing you to cross build the whole OS for any hardware target from many other OSes) and not too hard to follow. The source tree is structured in a way that makes a lot of sense (IMHO better than FreeBSD).


I don't know if it was the best, but one of the codebases that really helped me out in the mid-90s was XEmacs. It was portable to many kinds of systems and had lots of features that most applications never have to worry about (e.g., an embedded interpreter). I also got value out of GNU Emacs but XEmacs tried harder to be a good citizen on the X desktop and there were lots of lessons learned in there that I was able to leverage for the applications I was building at the time.


Ok just to come at this from another angle: my own (embedded C) code, after it had been gone over by a much more experienced and skilled maintenance programmer to bring it up to company standards. It wasn’t beautiful, even then, but it was crisp, super readable, and ironically closer to how I remembered it than the original. He hesitated to show it to me! Programmer ego and tact are funny things. Humbling, sure, but on the whole I was delighted.

The best - it compiled to the sane hex file.


Recently my favorite is core contracts of Uniswap V3 - https://github.com/Uniswap/v3-core Lots of nice ideas for a restrictive computing platform like EVM.


My own - hell is other people’s code.


The 7th circle of hell is my own from 3 months ago. I can't even blame someone else for the tragedy.


I think my code is regressing:

C++ from 14 years ago:

https://github.com/vlofgren/tunguska/blob/master/tunguska_3c...

A career of Java development later, and the code I wrote yesterday looks like this:

https://git.marginalia.nu/marginalia/marginalia.nu/src/commi...

My old code was so tidy. Can't believe I wrote code like that. Although back then I think I mostly used vim. Not having any sort of IDE tooling does sort of tend to force you to be a lot clearer about what you do.


The last "take the time that you need, as long as it's bulletproof" job I had was in the late 90's. The concept of sprints introduced a drumbeat that precludes solid engineering, imho.

> Not having any sort of IDE tooling does sort of tend to force you to be a lot clearer about what you do.

True, but then I wouldn't be able to play whack-a-mole with pointer symbols during weird code-pairing exercises.


At 15+ years of coding, I feel the greatest issue jumping across projects I’ve done (of a recent vintage) is getting into the paradigm.

I have a differing framework to an SPA, to an API, and to personal utility scripts. Amplified by adding in co-workers and contributors.

The Golden Question becomes how to communicate philosophy to a broad and diverse audience, be it co-workers or open-source.


I have the exact same sentiment.

My code looks like a poem, others looks like chicken scratch.


As my name implies - I’m half-serious in my sentiment. I’ve found many-to-most projects I’ve come across have personally-inconsistent conventions at a function level not to mention strategic architecture.

There is good code from other - but I feel many lack discipline in their initial approach and long term maintenance. In things as banal as variables. Not as a nit-pick but as a way of life.

It seems… concerning.


Haha, mine sure as hell isn't.

Whenever I try to polish some piece of code into some immaculate crystal it only takes a short while before I go and make some change to it and then it looks like crap again.

I try to keep it at a level where it doesn't get too out of hand it can't be refactored in an afternoon, while at the same time refraining from masturbatory polish.


The standard library of Julia, especially with the possibility to just enter `@code someFunction(params)` in the REPL to see the source of the method that the call would be dispatched to, the source can basically function as a second layer of documentation (the first layer being docstrings that are part of the source as well, but are usually accessed either via the IDE, or the help-mdoe of the REPL).


OpenBSD source code[1], because I think it represents good design. The code is as little as possible and easily understandable.

[1] https://cvsweb.openbsd.org


I would always recommend the OpenBSD coreutils over the GNU coreutils as they are much cleaner and less hacky. To be fair many of the tricks being used in the GNU code make the code run much faster but they're not a great starting point for a casual code browse.


Eye-opening but probably not "best": the Nullsoft Installer, circa 2002 (https://github.com/kichik/nsis). Its goal, besides being an installer, was to produce a small binary. So the source was remarkably pithy, which taught me a lot about being direct and to-the-point rather than aiming for beautiful abstractions or reusability.

Similar with Notch's Left4KDead, which implemented a fun zombie game for a Java small-code competition. A mirror of the original source is here (https://github.com/codingcampbell/Left-4k-Dead). I rewrote it in JavaScript as a Chrome App, in the process refactoring for readability (and sacrificing some of the code's beauty). https://github.com/sowbug/ChromeLeft4kDead


Redis. After struggling with extending QBE I thought that was how C was written in general, but Redis restored my optimism.


Redis is the only C or C++ project that I happily read the source to. Though I haven't done that since @antirez stepped back from the project. I imagine the code is still excellent...


ripgrep by BurntSushi (https://github.com/BurntSushi/ripgrep)


I wish there was a website like a code wall where you could see great code snippets and comments on why they are so great. Would be like a code museum. If anyone remembers the old coffee script source code with the explanation on the left, it's something like that I had in mind.


The Smalltalk-80 core classes. Some parts left me breathless on first reading in their beautiful simplicity, and some burnt permanently into my brain. Class Boolean, for example. I could probably reproduce it exactly now after not looking at it for decades.


I second that. Smalltalk-80 classes source code is an excellent reference to learning pure OOP style. https://github.com/dbanay/Smalltalk/blob/master/files/Smallt...


The one that I didn't have to read.

A mistake i see many engineers commit is obsess over their code and how "pretty" it is. What they seem to forget is that code is only read when it isn't doing what it's supposed to do. Granted when you do have to read it there are good and bad examples, but the question you should ask yourself is not "how can I make this code easier to read?" But "how can I make sure noone has to read this code". The code that performs this job is not always pretty. If it is impossible to make the code bulletproof then the best bet is usually to just make it really simple. Good code is nonexistent and if it has to exist it is boring.


For a lot of code, what the code is supposed to do changes over time, so no matter how correctly you write it the first time, someone will have to read it.


I remember liking the java sdk java source. Great small focused functions and nice use of newlines. You could tell the developers were forged in an era without syntax highlighting and large horizontal screens. Extremely scannable.


The Java standard library will forever be my baseline for “good.” Perhaps the C# beats it, but then the overall ecosystem of third-party libraries is such that it isn’t worth the slight improvements in design.

Node, by comparison, is a ghetto.


Boolean.getBoolean("true");


Yes! A fellow square! It's almost always a pleasant surprise to dig in and see how parts of java are actually implemented.


I don't know if it is the most elegant, or concise, or l33t, but I am in love with Polly https://github.com/App-vNext/Polly


Briefly used Polly at $OLDJOB and it has “Java” library vibes for me. Being on Node at work these days, I wish more libraries carried this quality.


I am definitely biased, but in general I like go source code? Meaning golang itself, and the standard library

every time I am not fully sure what some function from golang std library does, I just click away to its source code and it’s quite clear


The {BSD/OS, Free and Net}BSD sources in the mid-90s, coming from Linux and a source license for a commercial unix, both of which were mostly undocumented and didn't have any version control. The commercial unix was really grody, with lots of copy/paste of the same function with different bugs each time, and comments with bug numbers that meant nothing to us and didn't explain a thing.

The BSD sources were sanely laid out, documented and had a beautiful coding style that made the code easy to read. Free- and NetBSD even had version control.


Perhaps not the "best" source code I've ever read, but libVF.io had some beautiful code for what's generally gnarly system-glue code.

The libVF.io iommu setup code is a good example and inspires me to think that system-glue code doesn't need to be gross or impenetrable: https://github.com/Arc-Compute/LibVF.IO/blob/master/src/libv...

Another one I've appreciated reading (and learned more about 2d graphics from) is Pixie, a 2d graphics library written in Nim. It's strongly affected how I write similar code.

Here's the implementation of a fair subset of SVG paths: https://github.com/treeform/pixie/blob/master/src/pixie/path...

And one last one for basic algorithms which I'd use to teach intro to data structures any day: https://github.com/nim-lang/Nim/blob/version-1-6/lib/pure/al...

Of course Knuth's original code is still some of the best classic code. K&R's original C book is a classic.

(edited formatting and tweak descriptions)


PostgreSQL comes to mind (eg: see the query planner [0]). It is surprisingly easy to read through lots of interesting parts and see how they are working.

[0] https://github.com/postgres/postgres/blob/master/src/backend...


Since TeX and LLVM were already mentioned, I will casually mention the comments in Laravel's codebase which are all three lines long with each line exactly three characters shorter than the previous line. The art of computer programming at work.

Example (config file, but the entire codebase is like that): https://imgur.com/UnIUZmZ


Honestly...neurotic and counterproductive. You have to add too much useless words to make it fit. Most of these comments could be much shorter and easier to read. Also too much separators and whitespace around those comments.


Opinions differ. I personally like it, but I don't think I would manage do it in a reasonable large codebase. Still, I agree with the points brought up in the Reddit discussion on the topic (https://www.reddit.com/r/laravel/comments/20ovey/just_notice...), in particluar:

  I think it's awesome and I'm trying to do this too. It is a great trick that forces you 
  to re-read your comments and be as clear as you can. Also, you take the time to find 
  synonyms and look for typos. Overall it's a great way to learn how to be thorough.


+1 upvote for Laravel source code


This might be pretty controversial, but the Chromium source code has been a pleasure to work with for a few years. I was working on a proprietary fork of Electron and it was a delight to work with that code base vs some of the in house code I integrated into it. The web code search was also awesome to use.

https://cs.chromium.org/


Why is that controversial? Chromium is often cited as a well-written large codebase.


A lot of other examples given in other comments are quite the opposite. Clever code in long functions with single character variable names. Chromium shines in consistent naming, structure without much overelaborate uses of design patterns and general aim for maintainability and readability. I'm not saying there aren't those things in Chromium too (I've seen them), but they are well contained.

I've also seen a talk at CppCon (2019 I think) that spoke somewhat negatively about the code base. Can't find the reference, sorry.


LevelDB by Jeff and Sanjay.

https://github.com/google/leveldb


Redis used to be fantastic, I felt like I could read C without being particularly versed in it. I don't know if that's true anymore.


Was reading it the other day for shiggles. I’ll second you and say “it still is.”


Not that I understand any of the organic science behind it, but Timothy Stiles' Poly is some of the most beautiful Go code I've seen: https://github.com/TimothyStiles/poly

Blew my mind reading through it, honestly. Just perfect.


Ruby's Sinatra.

I read it before learning Ruby but surprisingly, the code made sense even though I didn't know the language.


While at Grad school, before taking a course on Systems programming, I spent a few days reading through Redis source code. It felt almost like poetry.. I haven’t had that level of motivation or time to read open source code like that again.. so there may be better examples.. but this was my best…


Quake


Smalltalk 80s entire source code.


I like Piumarta's code https://piumarta.com/software/maru/maru-2.4/

bsd code is clean

minikanren

some old lisp (le lisp or eulisp I forgot)


Here is the best code I have seen:

Yes, you are right. It is empty. The best code there is - is the code you did not had to write. It have no bugs, no latency. I am not being sarcastic here. I truly think that less code is better.


Shodan. I used its codebase to learn python and recommend it everyone else.


Got a link? I'm not familiar with Shodan and I've done some searching but not found anything immediately obvious



I found the RetroArch source (https://github.com/libretro/RetroArch) very accessible, when I added a simple title sanitisation it was easy to figure out what I had to change and where the changes needed to be. The accessibility of the source was particularly helpful as it was the first non-trivial C code I had come in contact with.


Idk about the best, but, this[1] implementation of hierarchical state machines is beautiful. It uses a few different template metaprogramming tricks to resolve state transitions at compile time! It's truly beautiful.

[1] https://accu.org/journals/overload/12/64/heinzmann_252/



Last summer, I followed the step by step code in Crafting Interpreters by Robert Nordstrom (https://craftinginterpreters.com).

Beautiful c code. As a 30+ year programmer, one new thing really stuck with me. He wrote all comments as sentences: first letter capital, finish with a “.”.


I know this isn't what you were looking for...but the literal source code for this website: view-source:https://www.lingscars.com/


D3.js was a pleasure to read. Especially as a developer who was starting to get out of my junior phase and really understand what I was doing in terms of JS.

It’s a very simple code-base in many ways. At the time it was 10k lines of mostly short pure functions.

The code examples were also really nice and explained a lot about how to work with SVG.

I owe some Thanks to Mike Bostok and his fellow developers.


Since diving into stable diffusion, I found the original code not very well organized not factored.

Then trying and looking at https://github.com/geohot/tinygrad which can implement SD, it’s really well written and ideas well organized, concise, and it works on multiple platforms well.


Yeah! The low line count for the code makes it all that more comprehendible compared to Compvis/stable-diffusion or huggingfaces/diffuser's code.


my choice would-be Professor Niklaus Wirth’s source code for “Tiny Pascal” in his seminal book “ Algorithms + Datastructures = Programs.” Here is a link: https://en.m.wikipedia.org/wiki/Algorithms_%2B_Data_Structur...

That compiler served as the blueprint for Borland tools.

philippe@fullpower.com


Welcome to HN Philippe!

> That compiler served as the blueprint for Borland tools.

When I was disassembling Turbo Pascal more than 20 years ago, I saw the similarities between the two, especially the scanner and parser where pretty much in line with the source code of Niklaus Wirth [1]. Even some of the global variables were the same. Back then I figured that since the source code of Niklaus Wirth was originally in Pascal, Anders Hejlsberg was actually "the Pascal Compiler" for the z80 (and later x86) translating the Pascal source into assembly. For me it seemed that Anders had a very good hand for register allocation, I remember the disassembly of Turbo Pascal was full of tricks, simply fantastic and elegant!

Here is one version Niklaus Wirth Pascal Compiler: [1] https://www.cs.hs-rm.de/~weber/comp/pascals3.html



I'm probably biased, but I particularly enjoyed going through mpv - https://github.com/mpv-player/mpv

I always found much of the FFmpeg API very unintuitive and much of what I now know about it I learned from reading through mpv. Hardware accelerated encode/decode, etc.


Not the code itself but the BeOS/Haiku system API is the best OS interface I've seen. So much nicer than Win32 or MacOS APIs.


I don't know if it's the best code I've ever read but this emulation library [0] of 8 bits computers is pretty well written, documented and designed: https://github.com/floooh/chips.

It's a good way to document old hardware with emulation code.



Backbone.js has an annotated source code page https://backbonejs.org/docs/backbone.html which I found very interesting at the time.


If you're looking for C, ReactOS. Example: https://doxygen.reactos.org/d3/d60/ntoskrnl_2io_2iomgr_2file...



I found the Blender codebase very intriguing. Overall just amazing piece of software and lots to learn from https://github.com/blender/blender.


Duff's device.


I can highly recommend checking out http://aosabook.org/en/index.html


Always liked reading the code in src.zip from the java sdk. Not too dense. Really dislike reading scala or kotlin code, though, feels like perl back in the days. But saves a lot of boilerplate.



Back in the 90s I enjoyed Nethack and Perl sources, had a hard copy of both. Both looked somehow human, with witty remarks and outright quotations from holy texts in case of Nethack.


All of the PC/GEOS source code... https://github.com/bluewaysw/pcgeos


Linux Kernel source is very good.

Wt[0] source code is also good.

[0] https://github.com/emweb/wt



I'm going to write some code on Monday. :-)


The source code of plan 9. Function fitted on an overhead projector slide and needed no comments for clarification.


Of course the one I wrote few months ago! When I re-read it today I realize how good I was at foreseeing all the problems that would eventually arise. The code has descriptive comments that explain not just what the code is doing but what it is supposed to do. I was very impressed with not just 100% line coverage but also complete branch coverage by rock solid unit tests. Sorry can't share the link because code is proprietary.


Angular code is pretty complex but well organized. I still have yet to understand most of it.


It's not too bad, you just need to know TypeScript.. And not like "I know TypeScript." on a resume, I mean "I know TypeScript™."


For Angular, I think the “problem” lies in the level of abstraction. AngularJS was a “Spring / Java” answer to web applications with Angular following the paradigm but introducing reactivity to the system. Not “wrong” per-se, the quality of code is great and so I could recommend it at a tactical level of “good code” but at the strategic it feels off.


> but at the strategic it feels off.

The problem with a reactive layout is that, if you're not going to just ask the user how they want to display things, you need to both read their mind and get it right 100% of the time.

Nobody can do that, so your web site shifts into mobile mode when I only give it half of my 3' display.


You're mixing up reactive programming and responsive design.


Postfix. Especially when compared to other MTAs such as qmail and exim.


Nginx felt pretty good


Git without a doubt.


async.auto is simply mind blowing to me.


Godot is nice


I would disagree. The C++ parts were very terse and unreadable.


for me jquery lib was very decent


I guess scikit-learn?


Delphi VCL and Zope


SQLite


Mine


Bitcoin


That’s absolutely not true.

Bitcoin the app is often mixing several layers of abstractions and several usage patterns together.

Is it for actually keeping track of money? Is it for APIs? is it for end users, or for servers? Is it CLI or a GUI app?

And it’s in C++, which is almost never readable.

And of course they have their weird names for everything (all the ScriptSigs etc), and the OP script which is at the same time too complex and too simple.

It’s surprisingly robust and it survived a lot, sure; I don’t take it down on that level; but the code even today got baggage of all the weird decisions Satoshi did when he made it.

It’s really not “good code” IMO.

Although they have improved it a lot in last few years, I will give them that. It was worse…


Yes, I would second this. It's hard to rewrite, but needs it in many places that I've read (in particular, the code to detect BIP9 etc soft fork activation is horrible).

To be fair, the slow polishing of a thousand hands continues. libsecp256k1 is tested to a level few if any FOSS libraries achieve, for example.


Yeah, the test suite is very very thorough.


no source code.


Mark Zukcerberg's original Facebook file /s




Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: