DEV Community

Julia Torrejón
Julia Torrejón

Posted on

How would you define high quality code?

What would be the main attributes of good code?

Discussion (65)

Collapse
fabe profile image
Fabian Schultz

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!

Collapse
ben profile image
Ben Halpern

I like this a lot. "Accommodation to changes" accounts for readability, organization, testing, and a lot of other things bundled in.

Coding only for the problem at hand right now: Bad.
Coding for every possible future need: Bad.
Coding to solve current problems while being accommodating towards future modifications: Good.

Collapse
citizen428 profile image
Michael Kohl

In his dry-rb at Deccan RubyConf last year Tim Riley said that well-written applications should be "change positive", i.e. conducive to future change. I made this expression part of my regular programming vocabulary and promote it every chance I get, like in this comment ;-)

Thread Thread
ben profile image
Ben Halpern

Yeah, that's a great framework.

Collapse
juliatorrejon profile image
Julia Torrejón Author

Coding for every possible future need: Bad.

I have seen this scenario a few times and it obviously delays the whole project because requirements keep changing and so does the code.

Collapse
alephnaught2tog profile image
Max Cerrina

This. There are few things that I feel like are as satisfying as being like "Oh crap, I need to make sure it can handle ABC" or "I need to change it for this new thing" and realizing you wrote it such that sure, it does need to change somewhere, but it has that capability for change without things getting messy. The opposite of having to add more and more logic to handle cases.

Collapse
juliatorrejon profile image
Julia Torrejón Author

A few points taken from Robert Nystrom are:

  • Key goal of software architecture: minimize the amount of knowledge you need to have in-cranium before you can make progress.
  • Get problem -> Learn Code -> Code Solution -> Clean up
  • Change to one piece of code doesn’t necessitate a change to another. We obviously need to change something, but the less coupling we have, the less that change ripples throughout the rest of the game.
  • Good architecture makes a huge difference in productivity. It’s hard to overstate how profound an effect it can have.
  • Good architecture takes real effort and discipline. Every time you make a change or implement a feature, you have to work hard to integrate it gracefully into the rest of the program. You have to take great care to both organize the code well and keep it organized throughout the thousands of little changes that make up a development cycle.
  • You have to think about which parts of the program should be decoupled and introduce abstractions at those points. 
  • Writing well-architected code takes careful thought, and that translates to time. Maintaining a good architecture over the life of a project takes a lot of effort. You have to treat your codebase like a good camper does their campsite: always try to leave it a little better than you found it.
  • Design requires a lot of experimentation and exploration. Especially early on, it’s common to write code that you know you’ll throw away.
  • If there is any method that eases these constraints, it’s simplicity. In my code today, I try very hard to write the cleanest, most direct solution to the problem. The kind of code where after you read it, you understand exactly what it does and can’t imagine any other possible solution.
Collapse
juanfrank77 profile image
Juan F Gonzalez

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

Collapse
cjbrooks12 profile image
Casey Brooks

😅wtf/min

Collapse
juanfrank77 profile image
Juan F Gonzalez

Exactly so, although I think that per minute would be a really big number hahaha.

Collapse
martinhaeusler profile image
Martin Häusler

This is the one and only true metric for good code quality. It never fails.

Collapse
juliatorrejon profile image
Julia Torrejón Author

An interesting point from Gridshore on this:

The most effective and certain method, however, is the code review. However, it is also very time consuming. It requires that one or more developers restrain from being (in the eyes of the customer) productive and give their attention to someone else’s code. Provided that the developer has a high standard of quality, it will definitely improve total quality of the code. Of course, there is the concept of pair programming, which could be seen as a form of continuous code reviewing. Highly effective, and can improve the skills of both developers.

These tools and processes can be very useful, but their overall efficiency depends on one thing: quality awareness within your development team. I’ll explain what I mean with “quality awareness”. It is the ability of developers to recognize code smells or failure to use design patterns at locations where they would typically be applied. This awareness it typically raises as developers gain more experience, but we’d typically like to help fate a little hand.

Collapse
jeikabu profile image
jeikabu

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.

Collapse
juliatorrejon profile image
Julia Torrejón Author
  • Reviewed and refactored within time-constraints

So, what would be the optimal time? Or is it somehow subjective depending on the circumstances?

Collapse
jeikabu profile image
jeikabu • Edited on

It's subjective and variable depending on the circumstances:

  • Skill and experience of the author (I tend to gloss over PRs by people that do consistently good work)
  • Difficulty/importance of changes
  • ROI for additional time spent etc.

There's an implicit assumption that you can't spend "forever" on a piece of code; at some point it's got to be "good enough" so you can move on. It's also subject to diminishing returns.

Collapse
thecodetrane profile image
Michael Cain

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.

Collapse
revskill10 profile image
Truong Hoang Dung • Edited on

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.

Collapse
juliatorrejon profile image
Julia Torrejón Author

How can you make your code faster?

Collapse
revskill10 profile image
Truong Hoang Dung • Edited on

"Make it fast" means you should use better algorithms or data structures to solve the problem. Because as you know, to solve one problem, there're many ways to do it. So it's also called optimization of the code to use better libraries, for example.

Collapse
citizen428 profile image
Michael Kohl • Edited on

I was about to post a comment saying pretty much the same :-)

Most code is a means to an end, not an end it itself. Maybe it's because I spent a lot of my career working at/consulting startups, but future proof code doesn't matter much if it took so long to write that the company has no future (been there). As the old saying goes, "it's null until you ship it".

Now of course every software developer who considers themselves a craftsperson will instinctively object to this statement. But to me the real craft in programming is finding the best possible solution to often competing constraints/interests, and business needs and time allocations are just as much part of this as runtime complexities and memory consumption.

I better stop now, otherwise I might end up adding to the "[t]ons of books" you mentioned ;-)

Collapse
ryan profile image
Ryan

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.

Collapse
juliatorrejon profile image
Julia Torrejón Author

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!

Collapse
tux0r profile image
tux0r

It is written in C.

Collapse
juliatorrejon profile image
Julia Torrejón Author

Could you explain why?

Collapse
alainvanhout profile image
Alain Van Hout • Edited on

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.

Collapse
devcamilla profile image
camilla

Just to highlight.. so you mean cake is considered good based on the experience of eating it.

Collapse
alainvanhout profile image
Alain Van Hout

In the case of cake, yes. How that translates to code is that code is also experienced as being good by how you interact with it later, i.e. modifying it in any way (rather than just looking at it).

Collapse
r0f1 profile image
Florian Rohrer

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.
Collapse
nestedsoftware profile image
Nested Software • Edited on

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.
Collapse
thomasjunkos profile image
Thomas Junkツ

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.

Collapse
vonheikemen profile image
Heiker

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.

Collapse
alanmbarr profile image
Alan Barr

I think what complicates this question for me is the intent of the code and future usage which is hard to predict. As a business owner I want the best bang for my buck to get to market as quickly as possible. As a maintainer of software my viewpoint is going to be more on how I can transition something over time. Very rarely am I thinking of how elegantly a solution is solved than how does it fit in an overall architecture.

Collapse
zeddotes profile image
zeddotes

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.

Collapse
ogfris profile image
Fris

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.

Collapse
xdefrag profile image
Stanislaw Mnizhek

Well, there is a lot of books, articles and talks for that matter, but all of them lead to two things: low coupling and tests.

If it's feature, it must be connected to codebase through interfaces and properly tested (mocks, benchmarks for critical parts etc).

If it's refactoring, tests must remain untouched.

Looks pretty simple, but it's not.

Collapse
zevenberge profile image
Zevenberge

One way to measure good code is that you need the knowledge of your problem to solve it, but no more. For example, if you need to fix a bug regarding to who financial transactions are sent, you obviously need to know which beneficiary to use in each use case. You should not need to worry about algorithms calculating the amount sent or interaction with external systems. This allows the developer to focus on one problem and one problem only.
Quite often this is achieved by modular abstractions, e.g. hide the external system behind an interface and supply the transferred amount through classes with calculated getter properties.

Collapse
lexlohr profile image
Alex Lohr

High quality code is

  • Maintainable: it must be readable, understandable, changeable, and easily removable
  • Effective: reaching the desired goal with the least mental/computational workload
  • Robust: fail only if neccessary, and then early and verbose
  • Secure: written with possible vulnerabilites in mind
Collapse
cjbrooks12 profile image
Casey Brooks

The projects I've worked with that had the best codebase to them actually made it difficult to write bad code with it. Bad code typically comes when there is too much going on and it is not well abstracted, so developers have trouble understanding it and end up writing more bad code, making the problem even worse.

In contrast, a good codebase has very clearly-defined structures and well-architected patterns that guide you toward the solution intended by its creators.

For example, Laravel was created for a specific purpose, and every API it opens up to developers drives you right where it wants you. You really have to put in a lot of work to use Laravel in any way other than it was designed for, and the way it encourages you to develop in it feels very natural and clean. The underlying codebase of Laravel is what I consider to be the best codebase I've ever seen and worked with.

Comparatively, Android's codebase is a bit of a mess. Don't get me wrong, I love Android and it is my favorite platform to develop for, but its codebase is messy and confusing, needlessly complex, often contradictory, and with very little direction given to the developer. It is definitely getting better now that it has matured the core framework, with Google starting to focus on better APIs for UI components and a more opinionated approach with Jetpack, but I still struggle to understand how most of the internal classes work, no matter how long I study their code.

Collapse
juliatorrejon profile image
Julia Torrejón Author

Therefore, a good codebase is the base of good code, isn't it? :)

Collapse
almostconverge profile image
Peter Ellis

I would look at the following criteria:

  1. When I make a change, how confident am I that the change will do exactly what I expect it to?
  2. Also, how long do I need to look for the right place to make the change?
  3. Are simple things simple to implement?
  4. How long do I need to look at the codebase to figure out "the system", i.e. how everything is organised?

These all sort of tie together, something with no unit tests for example is likely to fail on 1, whereas something with extensive but brittle unit tests will fail on 3.

Collapse
kayis profile image
K (he/him)

I think the quality of code has mostly to do with who needs to work with it.

Sometimes techniques that are hard to grasp can improve attributes of the software, like performance.

Some highly skilled people can write very performant code, but only other highly skilled people can work with this code.

Should we make the code more readable and easier to grasp but sacrifice performance so it can't be used by as much users as before?

I think 90% of the time the question is yes.

Write cleaner code and make it more maintainable, the bit of performance gains you could achieve aren't worth the trouble.

But sometimes it is worth it, sometimes you need to write high performance code so it works for the huge amount of people who only have slow devices to run your software.

Collapse
piotroxp profile image
Piotr Słupski • Edited on

My opinion is that high quality code has the following characteristics:

  • takes at max a week or two to merge your first PR due to verbosity and good architecture
  • is enjoyable to read and modify even if written in a language that is not your primary one, allowing you to introduce changes quickly
  • uses good abstractions and is kept solid and dry

I think those three makings translate to ease of introducing change, quick developer onboarding, rapid prototyping and pattern-first programming, greatly increasing productivity.

Very nice question @julia !

Collapse
joshichinmay profile image
Chinmay Joshi
  1. Easily accessible - simple file structure and well organised
  2. Self-explanatory - meaningful names for files, variables, methods, etc.
  3. That doesn't mean commented code is unacceptable.
  4. Aesthetics - Well indented - tabs size, spaces, etc.
  5. With test cases.
  6. Reviewed by collaborators.
  7. Readable. Not over optimised.
Collapse
codevault profile image
Sergiu Mureşan • Edited on

Ideally it should have all these properties:

  • Readable
  • Maintainable
  • Robust
  • Flexible
Collapse
inthetubes profile image
Master Splinter

It works and was on time.

Collapse
skkeeper profile image
Fábio André Damas

But it does matter. If you ever had to do any sort of code maintenance or expanding of existing code this is obvious. Code that is "clean"/"good" is easier to work with. "Does the code work?" is very important, but it doesn't even begin to be good code.

These books you mention, I would love to hear your arguments against their actual point instead of dismissing them by mentioning Linux or any other project, since that's not really the point.

Collapse
capsule profile image
Thibaut Allender

Well, if your answer is as undocumented as your code, I hope I never have to read any of your code...

Linux code follows Linus Torvalds principles, and they are notoriously harsh:
infoworld.com/article/3000564/linu...

So, no, it's not just about accomplishing the task.

Collapse
zimski profile image
CHADDA Chakib

Easy to read, easy to change!

Collapse
layzee profile image
Lars Gyrup Brink Nielsen • Edited on
  • Low overall cyclomatic complexity
  • Modular with clearly defined dependencies
  • Automated testing of behavior and use cases, including alternate paths and exception paths
Collapse
juliatorrejon profile image
Julia Torrejón Author

Don't you use manual testing at all?

Collapse
layzee profile image
Lars Gyrup Brink Nielsen

Sure, but the quality pretty quickly suffers in that you have no regression tests unless you very clearly specify the manual test cases and test steps. These manual tests have to be followed very carefully at least before each new release and deployment.

When I feel very confident about some code I leave out tests but often discover stupid bugs like a boolean being the reverse of what is expected in a specific state. Depending on the difficulty of the deployment process and the critical level of the project, I ramp up the amount of automated tests.

Collapse
n0ob__ profile image
anta

Professionally I do not even have an experience to use for reference, but as a student I would say this:
-> Quick run
-> Quick reading
-> easy to understand

Collapse
andrewlucker profile image
Andrew Lucker

High quality code is 1) not easily reproducible and 2) valuable.

note: this philosophy skews my coding conventions against the grain pretty hard.

Collapse
joshualjohnson profile image
Joshua Johnson

Quality code is stable and easily maintained.

Collapse
karthikchintala profile image
Karthik Chintala
  • Fewer lines of code in methods.
  • Code following SOLID Principles.
  • Code should be understandable easily when you look at it.
Collapse
nssimeonov profile image
Templar++

One, that keeps running a decade later and is still easy to understand, although it was modified many times by multiple developers over the years.

Collapse
mkenzo_8 profile image
mkenzo8

-Well executed
-Clean Code
-Documentation

(optional hehehe)
-Open source

Collapse
lmbarr profile image
Luis Miguel

Once I heard..."It is a good code if the cost to change the code is minimum" or something like that.

Collapse
ghost profile image
Ghost

Cheap and easy to maintain!

Collapse
mdshoilesk profile image
mdshoilesk

15