I feel like this just replaces one vague word "good" with a bunch of other vague words like "readable" and "maintainable".<p>Like of course, maintainable is good. But what makes code maintainable? When we're teaching new developers, what do we tell them to do to make their code maintainable? How do we distinguish between code that is maintainable, and code that is not maintainable? That's really the important thing; just knowing it should be "maintainable" doesn't particularly help.<p>And "readable" is even more complicated. Sure, there are some syntactic things that help readability—consistent indentation and spacing, good variable names, organized files, shorter lines. But beyond that it kinda breaks down. What makes a method readable? Well, probably a small number of lines, few branches, single purpose. That's good. But when you extend that to a codebase, you end up with code that you need to jump between a dozen methods to follow what happens in any given call. Is that readable? Or if you look at it from a class level, having a few methods where the whole chain of logic is in a single place is readable—but then you end up with giant god methods that do way too much. Is that readable? Presumably the balance is somewhere in the middle, but how do we recognize it? Just saying code should be "readable" doesn't really help.<p>Or "covered by automated tests"—definitely tests are helpful. Except for bad tests, which are harmful, and make fixing bugs or refactoring a painful process. So "covered by tests" can be good, or it can be bad, and adding the wrong tests can make your codebase worse. How do we distinguish between good tests and bad tests?<p>So I agree that the things mentioned are true about good code, but way too vague to help write better code.
I'm always surprised that "It works." is not #1 on these lists.<p>I get that as developers, it really matters quite a lot whether the code is good. But on a higher business level, software development is a tool, and the most important thing to the business is that it works. Working well and making it better and more efficient are incremental improvements to the business... but code that doesn't work is a deal breaker.<p>Beautiful readable, testable, maintainable code that fails to meet the business need is still a failure.
My definition is another: "Great code contains maximum entropy towards to its purpose while being easily understandable and maintainable."<p>Each part is interconnected to ensure quality and efficiency:<p>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.<p>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.<p>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.<p>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.<p>That good code does what its suppose to do and should be bug free should be a given :)
There is this paper [1] by John McCarthy on what he calls Elaboration Tolerance:<p><i>Elaboration tolerance is the ability to accept changes to a person’s or a computer program’s representation of facts about a subject without having to start all over.</i><p>This could make a good definition of what is 'good code'.<p>[1] <a href="http://jmc.stanford.edu/articles/elaboration/elaboration.pdf" rel="nofollow">http://jmc.stanford.edu/articles/elaboration/elaboration.pdf</a>
"Second, because if you write good code chances are that the product you are building will be much better."<p>If "better" means anything related to user experience, adoption or commercial success I think that correlation is about zero. Even the dumbest idea can be implemented by good code.
I'm not surprised readable is so highly ranked, nor do I disagree that it should be. I am however somewhat surprised that SOLID doesn't have a higher representation. I find that in general, as long as you keep code clarity and readability sacred, you can write testable code by following the SOLID principles. Seems to me it provides the basis of 'good code'.
Does that company even care?<p>Their team page at <a href="https://www.intenthq.com/about-intent/" rel="nofollow">https://www.intenthq.com/about-intent/</a> looks like a classic British social class structure; the people-people, so-called "movers and shakers" at the top, the mere techies all scurrying around on the bottom rungs, and QA almost falling off them. Even the office admin is presented above all the technical people.<p>Anyway, negative, small-minded and snide observations aside, here's my totally unscientific summary of their completely scientific survey:<p><pre><code> Readable
Simple (as in not entwined)
Functional/Verifiable
Maleable/Maintainable
Composable/Reusable
Efficient
</code></pre>
But of course all of these aspects are also very subjective.
Great code is mostly pure, dense, defines clean interfaces, and favors composition and reuse. Maintenance, testability , readability etc. are just side effects of well written code.
Well is it scientific or pseudo-scientific? In all seriousness, I assume when you ask someone what makes good code, they will assume the code is correct already.
OT: I need a css style editor that is point-and-click (or copy-and-click) simple. (I currently use Stylish.) I need something that lets me select a paragraph, adjust a style, and it automagically adjusts the class/id style for the page. This light text stuff blows- and unfortunately it kind of biases me against his ability to determine "readabilty" even though that is completely unfair.
I would define good as
Fit for purpose,
Maintainable, and id judge this primarily by SOLID
Tested, prefferably TDD aor BDD
and finally not iver commented, good code should convey what it does without the need for comments, and as code evolves, comments rarely are updated.
Good code looks like Carmack's code.<p><a href="http://www.codergears.com/Blog/?p=1313" rel="nofollow">http://www.codergears.com/Blog/?p=1313</a>
<i>Good code is written so that is readable, understandable, covered by automated tests, not over complicated and does well what is intended to do.</i><p>Couldn't agree more.