Characteristics of Good Code and How to Produce It

The article begins by emphasizing that writing good code requires a sense of quality and that many engineers lack a clear standard for what constitutes good code, often focusing only on functional correctness.

It then lists ten key characteristics of good code:

1. Robust (Solid and Robust): Proper handling of errors, exceptions, and system‑level failures, which often dominate product‑level code.

2. Fast (Efficient): Minimal resource usage, including CPU, memory, I/O, achieved through appropriate data structures and algorithms.

3. Maintainable and Simple: Clear, understandable logic that is easy to maintain; simplicity should not be sacrificed for cleverness.

4. Small (Concise): Keep code size minimal while preserving readability; brevity should not compromise clarity.

5. Testable: Code correctness must be verified through automated tests, often using Test‑Driven Development.

6. Re‑Usable: Encourage sharing and reuse of libraries or components to reduce development cost and improve quality.

7. Portable: Design code to run across multiple operating systems, often via abstraction layers.

8. Observable / Monitorable: Provide mechanisms for detailed runtime monitoring and state collection, especially for online services.

9. Operational: Consider operational costs, efficiency, and stability throughout the software lifecycle.

10. Scalable and Extensible: Support capacity scaling and future feature extensions, using modular designs and tools like Protocol Buffers.

The article then presents examples of bad code, such as meaningless function or variable names, lack of comments, functions with multiple purposes, poor layout, non‑testable code, and code that is hard to modify.

It discusses where good code originates, arguing that coding is only a small part of software development. Effective requirement analysis, system design, unit testing, integration testing, deployment, and continuous operation are all essential steps.

The author stresses that investing more effort in the early phases—requirements and design—yields greater returns than focusing solely on later coding and testing, because errors in early stages propagate costly rework.

Finally, the article compares the cost of modifying documentation versus modifying code, concluding that well‑crafted design documents reduce overall modification effort, as changes in code tend to be more expensive and error‑prone.