How would you define high quality code?

There's a really great chapter about this in "Game Programming Patterns" by Robert Nystrom:

For me, good design means that when I make a change, it’s as if the entire program was crafted in anticipation of it. I can solve a task with just a few choice function calls that slot in perfectly, leaving not the slightest ripple on the placid surface of the code.

That sounds pretty, but it’s not exactly actionable. “Just write your code so that changes don’t disturb its placid surface.” Right.

Let me break that down a bit. The first key piece is that architecture is about change. Someone has to be modifying the codebase. If no one is touching the code — whether because it’s perfect and complete or so wretched no one will sully their text editor with it — its design is irrelevant. The measure of a design is how easily it accommodates changes. With no changes, it’s a runner who never leaves the starting line.

Be sure to read the whole thing!

High quality code is the one that has a low wtf/hour ratio

Definition:

• More theoretical ideal; perfection is not attainable
• "Good" implies partially subjective
• Not binary.; there are many states in-between
• Not absolute; varies over time

Attributes:

• Well designed without being over-engineered
• State of the art, but not obscure or overtly clever
• Documented, but no superfluous comments
• Reviewed and refactored within time-constraints
• Optimal in time and space while avoiding premature optimization
• Meets business/technical requirements and common sense
• Leverages tools of the trade (testing, static analysis, etc.) if/when appropriate
• Maintainable and extendable in accord to its purpose

It's like art vs obscenity; I know it when I see it.

Personally, the more that code reads like prose, the higher quality it is. High quality code tells you the story about the business solution that it is implementing.

My favorite code is that which reveals to me something about the business that I did not previously know. Plus, like businesses, it’s written in a way to accommodate the future only when the future arrives.

To me, high quality code means less lines of code, but has more power. That power might be a useful abstraction, or it's just a useful algorithm to solve repeatable problems.
And if you want more quality of your code, make it easy to test, the easier to test a code block, the more quality that code block has.
And if you want even more quality of your code, make it fast. If your language couldn't make it fast enough, change the language.

Maintainable and efficient.

Maintainable means it is easy to understand, sensibly organized, it is painless to make modifications that should be expected (client wants to add another type of report), and as easy as possible to make changes that aren't (client wants a totally new feature)

Efficient means the code uses as few resources as possible to accomplish its job, so that it is as fast and scalable as possible.

It is written in C.

I'm going to use the #likeimfive approach here.

If code is like cake, then good code is like cake that you can enjoy eating and that will not leave you with stomach aches later on.

Note that 'doing what it is supposed to' is not an attribute of good code any more than 'being edible' is an attribute of good cake. That's just a fundamental real-world requirement for when someone asks you to write code / bake a cake. It doesn't have anything to do with either of those being good.

Uncle Bob says:

The answer to clean code is craftsmanship.

There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices and heuristics that a craftsman knows, and you must also grind that knowledge into your eyes and gut by working hard and practicing.

Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail, You must see them stumble and retrace their steps.

That is good advice for a beginner!

I’ll chime in with some characteristics I try to impart to my code:

• simple: keep the code as simple as possible. Avoid over-engineering.
• readable: make the intent of the code as clear as possible.
• orthogonal: give modules of code clear and independent responsibilities. Ideally modules that work together should be composable in any combination.
• tested: code should have automated tests by default.
• graceful with errors: modules should have well thought out considerations for edge cases and error conditions.

High quality code is code written by someone who cares.

What does it mean to care?

• Knowing the language beyond the syntax, i.e. writing concise ideomatic code

• Naming things in a way which helps understanding the purpose of things

• Grouping things together, which belong together

Or as Ward Cunningham once put it:

You know you are working with clean code when each routine you read
turns out to be pretty much what you expected. You can call it beautiful
code when the code also makes it look like the language was made for the problem.

I heared once, that instead of naming it »software engineering« it should be renamed to »software gardening«. This would connotate the constant effort which has to be put into a codebase in order to keep it beautiful and keep weeds at a minimum.

In my opinion "good" code is the one that is disposable. Is a codebase where you can identify with confidence the parts that need to be changed or removed in order to make a new feature or meet a new requirement.

You won't necessarily recognize it when you see it or when you write it for the first time, but you'll know when the times comes and you have to mantain it.

My personal definition is very subjective: A code is of high quality if

• someone other than the author can read and understand it, without investing too much time and coginitive effort
• it follows the conventions of your field (using familiar variable names, familiar abbreviations, familiar unit systems), whatever they might be.
• and one thing (source file / class / package) solves one task.

That's not necessarily true in all cases.

You write code as language for a computer. When you speak to another person, whether it's functional or an expression, you can say it in multiple ways -- all accomplishing the same task, in bad, good, great, and best ways. "Accomplishes the task" is ambiguous, as is the task's definition. For example, a task to display an RSS feed on a page is different for a junior dev vs an intermediate, or even another junior dev. It's very well different for different types of people, roles, cultures, etc.

Code quality measurement is like checking someone's health. If your life purpose was defined with 100% accuracy and our biotech was 100% accurate could one accurately determine a person's health exactly. Because we're far from that point, we make estimations based on multiple dimensions like weight, height, sugar levels, etc; similarly, we have test coverage, penetration/smoke testing, analytics, user group sessions, etc.

Some books might define it as "high quality code is when you don't break your software while doing small changes", which is totally not true, if you designe your program to play music, it shouldn't play movies too. For me, high quality code is when your codes are optimized, easy to read and well organized.
If you're afraid of not having a quality code then don't worry, i myself had some very bad habits of writing everything in one file 3 years ago but i fixed it as soon as i realised how hard it was for other people to read my codes. I fixed it with habits, you start by trying to write a well organized file then repeat it with every project you make until it becomes a habit.