Is code that runs fast but written with a bad and hard to understand syntax, good code?
Is code that runs slowly but written with a good and easy to understand syntax, good code?
5
Neither are. Good code is code that is both efficient during runtime and easy to maintain.
Code that run efficiently enough is good because the application runs efficiently enough, but if it is too difficult to maintain, it becomes a technical debt: something that will cost (possibly lots) to work with down the road, and should really be rewritten/refactored so it’s easily maintainable.
If code is easily maintainable but does not meet performance requirements, then it is not generally considered complete or working.
Generally speaking (for me at least), code gets written twice. The first time to make it do what it’s supposed to, followed by a refactor session (or multiple refactorings) to turn it into maintainable code.
With that said, there’s many other factors that contribute to what is “good” code, but those are two of the larger ones.
I’d offer you to take a look at the Code Complete book by Steve McConnell. A classic, and an entire book dedicated to writing “good” code: https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
1
There are many metrics for code quality, e.g.
- utility
- accuracy
- reliability
- maintainability, modifiability, extensibility
- usability
- portability
- testability, test coverage
- security
- performance
- internationalizability
- …
Which metrics apply and their relative importance depends on the situation. E.g. if you’re writing a one-off utility program for yourself, then maintainability, usability, portability, and internationalizability don’t matter. Time and code complexity spent on those factors would be counter-productive (except for learning how), and thus inconsistent with “well written.”
If you’re writing a stock exchange, then accuracy, reliability, testability, maintainability, and security are very important, and will increase the development costs.
If you’re writing a real-time program, it must reliably meet its time deadlines. It’s not faster = better. It’s reliability of meeting deadlines. E.g. if it runs a medical X-ray, being late to turn off the X-ray is a failure, possibly fatal.