-3

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?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Ibrahim Ipek
  • 105
  • 3
  • 3
    I've cleaned up your wording a bit. (BTW, your English is much better than my anything-other-than-English.) – Keith Thompson Jul 28 '16 at 00:12
  • The best book that I know of that touches on this subject is *Clean Code* by Bob Martin. Yes, the subject requires a complete book. **A word of caution:** *don't attempt to apply the SOLID principles to real code until you fully understand them.* – Robert Harvey Jul 28 '16 at 01:25
  • 1
    It is something of myth that doesn't exist in the Real World™ – whatsisname Jul 28 '16 at 03:03
  • Possible duplicate of [Clean readable code vs fast hard to read code. When to cross the line?](http://programmers.stackexchange.com/questions/89620/clean-readable-code-vs-fast-hard-to-read-code-when-to-cross-the-line) – gnat Jul 28 '16 at 03:50
  • 1
    Good code is code that fulfills the requirements, i.e. does what it is supposed to do, while being as simple and readable as possible given the constraints of the requirements. E.g. if the code is *required* to be fast, then simplicity may need to be sacrificed for the purpose of optimization. – JacquesB Jul 28 '16 at 08:13

2 Answers2

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.

Jerry101
  • 5,367
  • 1
  • 15
  • 19
0

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

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
jleach
  • 2,632
  • 9
  • 27
  • I downvoted this in favor of Jerry's answer because of the opening statement. Often efficiency and readability are trade-offs. The right choice depends on the context. Either can be a good choice. – Martin Maat Jul 28 '16 at 05:49