DEV Community

Alex Kharouk
Alex Kharouk

Posted on

When is your code 'good enough'?

When do you decide your code is good enough? Is it after refactoring a dozen times or when you've check marked every task you had to do?

Is it when there's not a single error or are you just happy that it doesn't crash your terminal when you run it?

I ask because I've been reading Katrina Owen's and Sandi Metz's book titled 99 Bottles of OOP and they talk about what they think is good code.

As a beginner, I fall into the write the code; run it; pray category.

So tell me Devs. When do you decide your code is good enough?

Top comments (21)

biros profile image
Boris Jamot ✊ /

My code is good enough when I can understand it one week after :)

kataras profile image
Gerasimos (Makis) Maropoulos • Edited

Better one, after a month or further, take for example the iris web framework, it has so many modules inside it and some of them are 6 months+ old and I still remember the exactly file and where a particular piece of code is related to users' question or contributors inside it. This is how you should do it, but it's a good practise to take some time and read section-by-section your own code every 1-2 weeks, this can be done on sundays for example.

kharouk profile image
Alex Kharouk

That's a great answer.

paulomonteiro1 profile image

Thats an excellent strategy!

itamarst profile image
Itamar Turner-Trauring • Edited

"Good code" or "Bad code" isn't a practical or useful way of thinking about it, because it's not just about the code, it's also about the situation and goals.

A better way of thinking of it is "fitness to purpose": does this code fulfill your goals?

  1. You might need to maintain the code, which requires one set of criteria...
  2. or you might run it once and throw it away.

Those two situations result into two different kinds of fitness to purpose, two different ways of judging your code.

Longer version:

ignoreintuition profile image
Brian Greig

I consider anything that is going to be maintained for any significant amount of time to require some degree of quality.

itamarst profile image
Itamar Turner-Trauring

It's the other way around: "quality" has no meaning except in regard to your goals.

If maintaining something is a goal, then your code needs to meet certain properties, which you then call "quality". But "quality" is not a property of the code itself, separate from its goals: it only makes sense in a specific situation.

Thread Thread
ignoreintuition profile image
Brian Greig

Maybe I am a bit biased because my background is in enterprise software so code is maintained across dozens, if not hundreds, of developers and even small changes can persist for years. Having well-defined code quality standards that are shared across teams is imperative.

Thread Thread
itamarst profile image
Itamar Turner-Trauring

Right, and that's a specific situation with specific needs. Not saying you don't need those standards, just saying those standards are situational.

ignoreintuition profile image
Brian Greig

I look for the following things:

  • does it meet the requirements
  • are all defects mitigated
  • is it fault tolerant
  • does it have a high degree of readability
  • is the documentation comprehensive
  • is it tested / testable
  • are we following DRY principals
  • is it loosely coupled to other components
  • are there any security risks

These are what I conder to be code quality metrics. If the above are met then the code is good. Obviously, some of these are easier to identify than others. You have to define your own thresholds for things like "What is comprehensive documentation?" This kind of thing can be more subjective than something like: "Are all defects mitigated?" which is just a simple yes / no answer.

stevieoberg profile image
Stevie Oberg

I try to keep my process simple, I want to be able to come back to any code I write in a few weeks and not spend the same amount of time understanding it as I did writing it. Code is meant to be read, or else we'd be writing all our programs in machine/assembly language.

So it's good enough when it runs correctly, well tested/covered by tests, and it's easily read.

jillesvangurp profile image
Jilles van Gurp

Very simple. It is ready to deploy to a live production environment when it is clearly better than what it replaces. If you are doing continuous deployment, you take these decisions multiple times per day. It's not uncommon for me to have the next change ready to go before the previous one is done deploying (around 10 minutes).

Some changes are just a 1 line fix. I love those changes. They are easy to reason about. Ironically, the longer you wait the more uncertainty builds up. Pushing out big deltas requires more thinking. What changed? Are all those changes valid? Etc. That's why I do the opposite: I push out lots of small changes that each improve things in a meaningful way. The only question that needs answering is: "is it better?". If yes, don't wait and deploy right away. You can worry about making it even better with your next commit.

The flip side is you need a safety harness of automated tests and deployments and preferably some automated code checks, linters, and static type checking. These help answer you whether things are better; or at least whether they are not worse. The more often you deploy the better this gets. Deploying with confidence and without fear is a good thing.

Also, just because it is better doesn't mean it is perfect or done. You are never done perfecting your live product. But separate the questions about being done from being ready to deploy.

voins profile image
Alexey Voinov

It's good enough, when I can see code smells in one layer only. :) I mean, when I look at the code, and I know exactly what I need to do to improve it, and I don't have a feeling that everything is so tangled up, that I just don't know when to start.

But I work a lot with legacy code. :) It's really rare event when I write something from scratch.

bgadrian profile image
Adrian B.G.

What other said, mostly:

  • leave the code better then I found it
  • it works and solves the problem
  • passes tests and my own critique
  • add a salt of defensive programming and security concerns

If time allows or special cases:

  • profiling and performance upgrades
  • documentation
  • more extensible code/good practices

If it is a new feature on old code, before all that I have 2 extra steps:

  • delete dead code
  • refactor so the new feature can be easily added
stealthmusic profile image
Jan Wedel

I develop test-driven. That means, the simplest code that makes the test green ist good enough. And write test until I have met all the requirements. Follow clean code rules while implementing.
Do not attempt to optimize anything wirhout an actual need. That’s basically it.

ferricoxide profile image
Thomas H Jones II

Speaking as a perfectionist...

Truthfully? Never. Code can always be better: do more; gracefully handle more edge-cases; be easier/more-intuitive to use; run quicker; produce more meaningful errors; etc. What usually drives when I turn over code is the calendar.

And, while I frequently write with a "this is a first draft, I'll smooth it out later iterations," the opportunity to iterate rarely comes. Usually, someone comes along and says, "does it do 'X', yet? Ship it." Which suuuuuucks. You know what you've allowed out is hot garbage, even if it is serviceable (and better than nothing). You also know that, eventually, someone's going to come crying about ...and it will have been so long since you touched the code that "iterating" is more like "rewriting" ...frequently under the greater pressure of a tool that's become critical but needs to be pushed out to the junior guys.

gauravchaddha1996 profile image
Gaurav Chaddha

If the code solves the problem at hand without being too smelly or difficult to understand, the code is good. IMO one should refactor until one can change one factor of code without worrying about another (Like change UI without worrying about breaking functionality). Although remember to not over-refactor your code. Stop when it will make the code more complex to understand. Refactor only until code is understandable and isn't that hard to understand.

h4ckz3r profile image

When it passes all the tests and I'm not the only one who understands it ;)

kharouk profile image
Alex Kharouk

The dream code!

rapidnerd profile image

I consider my code good enough when it works, but when it becomes code that other devs can follow, work around and understand that's when it becomes beautiful.

tobiassn profile image
Tobias SN

My code is good enough when I can see what it does, and it works