My definition is another: "Great code contains maximum entropy towards to its purpose while being easily understandable and maintainable."
Each part is interconnected to ensure quality and efficiency:
1. Maximum entropy means that your codebase should contain as much concentrated "information" as possible in relation to its size. Free of copy & paste code and repetitions that can be reused in libraries, methods and classes. This ensures less code to maintain , easier to spot bugs and easier to spot patterns.
2. Understandability (that includes readable): That means no blob classes or methods with an infinite number of purposes. Each layer of abstraction simple enough to keep in mind in its entirety.
3. Maintainable: It should be bug resistant, making it hard to do the wrong things and easy to do the right (for example putting required parameters into constructors rather than fields or properties). You should be able to replace and/or modify individual parts without side effects. Having as little code as possible also helps with this.
I think "covered by automated" tests are nice ... in some cases. It is far from a rule that they're a panacea for every kind of project, code and/or situation nor are all kinds of code wort the effort (models & algorithms: yes, UI: usually no). It also depends on the team and methodology.
That good code does what its suppose to do and should be bug free should be a given :)
I think I get what you're saying with "maximum entropy", but it's the wrong term for what you're trying to express. Really unreadable, terse code is highly entropic, but it's not good code. If you use descriptive variable names, that decreases from the entropy of the code.
yes maximum entropy = high information density. When you compress a file it usually leds to higher entropy. I agree that being terse in itself isn't the primarily goal, that's why I said "while being" ie has to reach the understandability and maintainability criteria as well
If you think I'm using the term wrong I'd appreciate a reference, thanks
Is that in order of importance? I'd put readability above everything else. Compact code is nice but I'd rather have self-documenting code, even if it means several more lines of code added to the functions.
Its hard to put a clear hierarchy of importance since it's a rather fine balance. As you say going for maximum compactness makes it much less understandable (Regex anyone?). That's also why i used the term entropy rather than compactness.
It's not primarily the number of characters we're optimizing for but code as information dense and devoid of redundancies as possible.
I actually think you should be verbose to the point of building a DSL-like syntax for your solution to improve readability. Even for instance addint small properties and methods that simplifies reading. It's much easier to read
if (CanWrite && WillFitDisk)
than
if (File.Position != File.EOF && Disk.AvailableSpace > Buffer.Size)
Even if reusability of those small methods and properties aren't high
So I see it as "compact" as possible as long as you fulfill understandability and maintainability.
high entropy in information theory is as much information per unit as possible as I understand it, but I confess I had to look it up to make sure :) I think the confusion is from physics where entropy is more about disorder
Each part is interconnected to ensure quality and efficiency:
1. Maximum entropy means that your codebase should contain as much concentrated "information" as possible in relation to its size. Free of copy & paste code and repetitions that can be reused in libraries, methods and classes. This ensures less code to maintain , easier to spot bugs and easier to spot patterns.
2. Understandability (that includes readable): That means no blob classes or methods with an infinite number of purposes. Each layer of abstraction simple enough to keep in mind in its entirety.
3. Maintainable: It should be bug resistant, making it hard to do the wrong things and easy to do the right (for example putting required parameters into constructors rather than fields or properties). You should be able to replace and/or modify individual parts without side effects. Having as little code as possible also helps with this.
I think "covered by automated" tests are nice ... in some cases. It is far from a rule that they're a panacea for every kind of project, code and/or situation nor are all kinds of code wort the effort (models & algorithms: yes, UI: usually no). It also depends on the team and methodology.
That good code does what its suppose to do and should be bug free should be a given :)