41–50 of 216 posts
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible. Good code is working code, code that pays the bills. Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
The first is Jones Forth (https://github.com/nornagon/jonesforth), start with jonesforth.S and move into jonesforth.f. I really enjoyed following along with it and trying my hand at making my own stack based language.
The other is Xv6, a teaching operating system from MIT (https://pdos.csail.mit.edu/6.828/2021/xv6.html), not all the code or implementations are top notch but it shows you non-optimized versions (just because they're simple and more readable) of different concepts used in OS design.
If you're interested in the embedded world, there is a really neat project I've been following that feels a more structured and safe (as in fault-tolerant) while still staying pretty simple (both conceptually and in the code itself): Hubris and Humility (https://hubris.oxide.computer/).
I’m sure I’ve seen some HN posts about this article, but I can’t remember the content of such.
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible. Good code is working code, code that pays the bills. Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
Code that works is, usually, acceptable. But code that is acceptable while making no unnecessary maintenance trade-offs is much better. Good code is code that uses standard techniques in standard ways to achieve a result without being verbose or inefficient. But that is a much higher bar than code that is literally good enough.
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible. Good code is working code, code that pays the bills. Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
This mentality is how you end up inheriting terrible codebases.
This isn't exactly a repo to look at, but the book "Clean Code" is a fantastic read for learning how to write good code. It does have a lot of examples in it, and does a great job explaining everything. https://github.com/jnguyen095/clean-code/blob/master/Clean.C...
I’ve heard people say it’s a good book if you just ignore all the bad stuff, but how are you supposed to know what the bad stuff is if you’re a beginner? I think it’s time to stop recommending this.
Earlier quoted context omitted.
This mentality is how you end up inheriting terrible codebases.
I would rather write “bad” code that lasts long enough to be inherited than write perfect code that sits idle in a repo because I missed the market.
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible. Good code is working code, code that pays the bills. Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
Good code "is isolated enough that rewriting it won’t cost absurd hours." This is the hard part.
This isn't exactly a repo to look at, but the book "Clean Code" is a fantastic read for learning how to write good code. It does have a lot of examples in it, and does a great job explaining everything. https://github.com/jnguyen095/clean-code/blob/master/Clean.C...
https://qntm.org/clean has a great discussion of all the things that are wrong with Clean Code.
Ultimately I think the single most important rule for clean code is: skinny controller, fat model. If you are doing batch data, then this applies still I think. You should have all of the logic you can in the model, avoid data objects. And the code paths that alter things should be as thin as possible. I honestly think it is better to have a 5k line model if it avoids more.
The most unlcean code I have seen usually falls into the abstracted out processes in financial instutitons where they follow Clean Code advice and everything are a bunch of functions passing around some big fat objects full of getters and setters, and changing any functionality means adding changes somewhere in the process to check state and alter the state, which leads to loops and if statements everywhere to see which account type it is at each point etc.
But in OOP programming its supposed to be objects sending messages to each other. Every object should know everything about itself, which is what a fat model demands. Any more abstraction than that seems to get in the way.
Earlier quoted context omitted.
Good code "is isolated enough that rewriting it won’t cost absurd hours." This is the hard part.
Yes, and it also is the point I think most people here are missing.