Ask HN: What are your favorite open-source codebases?

[sarthakjshetty]

Hey HN! I wanted to know what are your favorite open-source codebases that are high-quality and well documented?

I'm a beginner programmer, and a common suggestion here on HN is to look at high-quality, open-source codebases, as a technique to write better code and for inspiration.

Please post links below, and if possible, why you like it so much!

I work as a robotics researcher and code primarily in C++ and Python, but feel free to link projects outside these languages as well.

Thanks!

[nikivi]

I liked these ones:

https://github.com/TheThingsNetwork/lorawan-stack (nice docs + contribution process)

https://github.com/cli/cli (well made cli, awesome --help & flag conventions)

https://github.com/denoland/deno_website2 (next.js codebase with serverless cloudflare workers being used)

Mostly as it uses tech I like using already.

[oumua_don17]

Blender [1] and [2]

[1] https://wiki.blender.org/wiki/Source/File_Structure

[2] https://developer.blender.org/diffusion/B/

[op03]

Kiwix - makes it possible to run a local offline copy of wikipedia/stack exchange etc etc.

On top of that I have Elasticsearch/Kibana allowing me to build up my own little private search engine.

[sarthakjshetty → op03]

That's very intersting! Do you mind sharing the code here?

[op03 → sarthakjshetty]

You can start here - https://www.elastic.co/blog/loading-wikipedia

[MaxBarraclough]

Which language are you learning? It won't be possible for people to give you good suggestions if they don't know this.

[sarthakjshetty → MaxBarraclough]

Thank you for that suggestion. I've edited the question now.

[jacquesm]

Sqlite.

Redis.

[MaxBarraclough → jacquesm]

Codebases, not databases. I misread it the same way at first.

[jacquesm → MaxBarraclough]

And I meant codebases, not databases.

The codebases of Redis and Sqlite are very, very good.

[MaxBarraclough → jacquesm]

What do you make of Postgres?

[jacquesm → MaxBarraclough]

Very nice but much too large for a beginner to study unless you intend to go for a project of that scale (which I would not advise a beginner to do anyway).

Every decimal order of magnitude increase in code size brings along its own kinds of complications. 10 line program -> throwaway, not all that important to document properly unless it is APL or some other super dense language (and in APL 10 lines would be quite a handful), likely no higher level structures required. 100 Lines -> code that will hang around for a while, you'll need to structure it properly for long term maintenance but in the short term you can get away with a lot, functions are a must, classes and other abstractions would be unnecessary overhead, but tests may already be useful (and should not be included in the linecount). 1000 lines -> now you are really programming, code organization becomes a more dominant factor in when and if you will complete your project, likely it will be worth breaking it down into two or more modules, tests will start to really show their worth. 10K lines -> multiple modules a must, well documented interfaces a must, documentation a must if the project is to survive long time, testing at interfaces is the way to ensure code won't break unexpectedly, probably multiple people working on the project. 100K lines -> you are now well into team territory, somewhere between 10K lines and 100K lines one of the original contributors probably left, this forced the remainder to deal with the fall-out of a sudden knowledge gap which in turn forced them to deal with that and to pre-empt further knowledge loss by code standards, documentation standards, quite a bit of process and other overhead that does not necessarily deal with the code itself. Careful version control and release schedules are also a must at this level, likely there is now a separate QA role. 1M lines and up-> Code is no longer the dominant factor in keeping this codebase alive, documentation and process however are. Almost none of the original authors is with the project. If it was managed properly then there are no 'no go' areas, otherwise there will be a substantial amount of poorly understood legacy code that lots of people would like to tackle but nobody actually dares to for fear of upsetting things.