3 ms·

A good way to write better code is to read good code. Go find some open source projects you like and skim read the code! Personally, I like to go back in the g

by gitgud 6y ago

A good way to write better code is to read good code. Go find some open source projects you like and skim read the code! Personally, I like to go back in the git history to when things were simpler and see the changes to the codebase that solved specific problems they had, e.g; scaling, reusability...

ed25519FUUU 6y ago
A fun website idea: curated refractors, where commits and design decisions are laid out for readers to skim and enjoy.
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 ago
  also, 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 ago
    My 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 ago
  When 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.)
baron816 6y ago
Going and finding oss project that are similar to the things you’d actually write is hard enough, but then also figuring out if the code is any good when you don’t know what good code looks like is an even greater challenge. Even if you pull that off, you’re not really going to know why parts of it are any good. Ideally, you’d find a mentor who can review your code and give you pointers on how to improve it, with explanations on why those things would help. Those mentors aren’t easy to find either, but still...

by gitgud 6y ago

ed25519FUUU 6y ago

A fun website idea: curated refractors, where commits and design decisions are laid out for readers to skim and enjoy.

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 ago
also, 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 ago
  My 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 ago
When 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.)

baron816 6y ago

Going and finding oss project that are similar to the things you’d actually write is hard enough, but then also figuring out if the code is any good when you don’t know what good code looks like is an even greater challenge. Even if you pull that off, you’re not really going to know why parts of it are any good. Ideally, you’d find a mentor who can review your code and give you pointers on how to improve it, with explanations on why those things would help. Those mentors aren’t easy to find either, but still...