51–60 of 216 posts
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.
This is not relevant to the vast majority of developers, realistically (and is an important caveat to your original comment).
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.
Writing bad code that just "gets it done" is the proverbial broken window. It's how you end up with shitty code-bases that get shittier with every change, until it all collapses under its own issues.
Doing this on established code-bases is basically what the classical duct tape programmer does. Sure, you deliver "business value" in the short term (normally to claim credit and gain favor) but at the expense of everything and everyone else.
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.
Earlier quoted context omitted.
https://qntm.org/clean has a great discussion of all the things that are wrong with Clean Code.
I don't like clean code, and like the author I find the things presented in Clean Code to just make incredibly inscrutable code. The worst code bases I have seen have been the ones with no code plans at all, and the ones that use Clean Code and Gang of Four like a bible, both are equally mazes of spaghetti. Clean Code I really just don't agree with, and I think this author lays it out well. Special design patterns an…
Any code that is used and minimally hated by a large number of people is good code in my opinion. It's valued by its users, and ultimately that is what matters.
It may not be perfectly DRY, use popular abstractions, or whatever people today think of as ideal code, but successful software projects solve real problems every day. The authors have likely done a good job of balancing usability with code quality. And I think that's the best we should hope for.
Earlier quoted context omitted.
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.
>because I missed the market This is not relevant to the vast majority of developers, realistically (and is an important caveat to your original comment).
Earlier quoted context omitted.
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.
Writing good code doesn't necessarily take more effort than writing bad code; in fact, my experience tells me otherwise. Teams that write good code iterate faster.
But in a way you're right; if there is no to ensuring your code follows more conventions, go for it. That's exceedingly rare, however, as a situation to be in.
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...
Someone who does writes quite clean code is in my opinion Tsoding: https://www.youtube.com/@TsodingDaily Strongly recommend his YouTube channel!
Earlier quoted context omitted.
I don't like clean code, and like the author I find the things presented in Clean Code to just make incredibly inscrutable code. The worst code bases I have seen have been the ones with no code plans at all, and the ones that use Clean Code and Gang of Four like a bible, both are equally mazes of spaghetti. Clean Code I really just don't agree with, and I think this author lays it out well. Special design patterns an…
The popular OOP seems to be exactly the opposite of what OOP was meant to be. If you get into the original intentions, it honestly starts to sound more like FP.
Popular OOP passes Structs around (they just call them records or POJOs or whatever) through a bunch of "classes" that do x. But you could rewrite the code from Java or C# or C++ into C or Cobol and it basically is the same. Its just imperative code with classes as a nice way of getting rid of globals.