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)
My code is good enough when I can understand it one week after :)
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.
That's a great answer.
Thats an excellent strategy!
"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?
Those two situations result into two different kinds of fitness to purpose, two different ways of judging your code.
Longer version: codewithoutrules.com/2017/11/07/no...
I consider anything that is going to be maintained for any significant amount of time to require some degree of quality.
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.
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.
Right, and that's a specific situation with specific needs. Not saying you don't need those standards, just saying those standards are situational.
I look for the following things:
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.
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.
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.
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.
What other said, mostly:
If time allows or special cases:
If it is a new feature on old code, before all that I have 2 extra steps:
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.
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.
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.