How to create good code

[[155438]]

Someone recently emailed me asking me how to write good code. I was feeling a bit under the weather, so I rambled a bit. I’m feeling better now, so I wanted to share the following thoughts because I think they’re an interesting starting point for this important discussion.

At the time, I wrote:

1. Good code doesn't just compile, it communicates. It talks to you now, and it talks to you later when you maintain the code. It's understandable to your team and anyone else who looks at it from the outside.
2. Good code values ​​reliability and testability over clever tricks. If it needs to clearly express its intent and results, good code will tend to use one or more extra steps to express it.
3. Good code also takes into account its usage. The requirements for a piece of code that runs a million times and runs it only once are different, just like a tree in the forest and a lonely tree.
4. Good code, even when broken down, can be broken down into reasonable units, rather than into a massive monolithic implementation.
5. Good code is not just implemented once or twice, but also reviewed and refactored. This makes it possible to make it the best and most robust implementation.
6. Good code takes globalization into account and provides for potential users of different cultures. Adding internationalization and related accessibility is really a matter of code, not just an afterthought.
7. Good code not only considers what specific environment it runs in today, but also considers how to adapt to these environments that may change over time.

That’s what I thought of. What do you want to add, delete, or modify about my list of “how good code is made”? I look forward to seeing your thoughts.

renew

Seivan Heidari suggested adding: Good code does not expose internal implementation details when exposed as an API to the outside world.

Anonymous suggested adding: Good code is natural. Good code does what you need it to do and is delivered on time. The rest is bullshit.

Dave DeLong suggested adding: Good code inspires awe in those who read it, and inspires those who read it to write good code of their own.

Paul Cantrell suggested adding: Good code pays attention to trade-offs. It makes trade-offs based on engineering, not absolute dogma. It also doesn't make tools or techniques in-group status markers.

Rainer Brockerhoff suggested adding: Good code can be easily reused (even after several years) and can be extended or adapted with just a few lines of code.