[externalreality]

I would argue that what makes code "good" is completely subjective which is why I don't spend too much time thinking about it.

The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.

There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".

[jimbokun]

"The only criteria I have for good code these days is "Does it work", "Can I understand it"."

Which of course, are not trivial to achieve by any means.

Maybe also add "Can my coworkers understand it?" Which might be a very different metric.

"I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later."

If you want to get very far with any of those, you will need to write "good code", as you have defined it. So maybe a better way to understand good code would be to read the code of large projects implementing the things you want to learn about?

[externalreality]

I don't know. Procedural code in Golang is pretty trivial - you basic constructs are regular in the selection, iteration, and sequence sense with a sprinkle of interfaces and some CSP constructs for concurrent design. That covers like 99% of what you need to write good code. I'd say pattern matching is pretty helpful Ala ML, Haskell, Rust. Beyond that all the GOF and Solid and all that jazz seems to do way more harm than good IMHO.

> If you want to get very far with any of those, you will need to write "good code"

If you have ever looked at the code of the most successful programs the code is anything but "good". Have you glanced at the Linux Kernel code lately? But again, "good" is very subjective. The Linux Kernel works well enough to server the purpose of millions of users and enough people understand it. Its good code!