3 ms·
This is often repeated advice, but is less valuable without a sugegsted list of projects known for code quality, or even better a list of projects known for cod
by udev 6y ago
This is often repeated advice, but is less valuable without a sugegsted list of projects known for code quality, or even better a list of projects known for code quality and relatively simple code base.
I often find the best service someone experienced can render to someone unexperienced is the service of curation, i.e. hand pick from the vast amount of available options a few that are likely to help.
- regulation_d 6y agoalso, studying only libraries might encourage people to think that the proper amount of abstraction is higher than it might be for an actual project.
- MiroF 6y agoMy take is that designing good code has a lot to do with the art of learning what abstraction to construct. Seeing lots people design different abstractions for different use cases is useful.
- stevekemp 6y agoWhen I started down this path I just picked applications that I used a lot. For example I read the source code to `less`, and the manual. Despite "knowing" less I learned a lot from reading the manpage and reading the code. Same with GNU Make. I could say I knew it before I started, in the sense that I'd written simple Makefiles and knew how to run `make -n` , `make -j4`, etc. But reading the manual from start to finish, and reading the code meant that my knowledge was more complete. Some programs have terrible source code (e.g. "telnet"), and others good (e.g. "redis"). I think that a list of examples might be useful, but more useful still would be for people to choose things they know, and they use. Reading all about the design of postgres might be wonderful, but if you're not actively using it then the details aren't going to be so memorable. Better yet, because I read the source to programs I used I was even able to contribute bugfixes to them. (In the case of less/make at least. Not always.)