What is "Good" Code? A Developer's Perspective
When talking to software developers, you'll come across a bunch of jargon to describe code. "Dry", "Elegant", "Sugar", and the like. Shockingly, something you rarely hear used to describe code is "Good". And I think the reason why is because defining what makes code "good" isn't always clear. And as you look at more code, you start to see that every developer has different ideas of what makes good code. Here are my opinions as a developer on what exactly I look for when I look for "Good Code"
Readability: The Cornerstone of Quality
First and foremost, good code is readable code. I've spent a lot of time in the algorithm mines, and there are a lot of very concise, elegant solutions to very complicated problems. I've even taken some of those ideas and used them in my own projects. It's a great feeling to solve a nightmare of a problem in only a few lines, at least in the moment of solving. But looking back on your solution weeks or months later (or even just far enough into the project that you haven't thought about that part of your codebase recently), you suddenly find yourself having to pick apart all of the shorthand, the syntactic sugar, and figure out what the hell is actually happening in your code.
Now imagine that you're working with a team of developers who've spent their time actually making things instead of practicing algorithms (the dream!), and you've sprinkled these clever little solutions all over the code base. The time you may have saved yourself you're now wasting from others, and the bigger your team is, the more time gets cast into the void.
The majority of time spent in a codebase isn't writing it, but reading it. So spend the extra time in the writing, and you'll make dividends in the reading.
The Art of Commenting
With my thoughts on readability, you probably think I'm a stickler for extensively commented code. Surprisingly, I think the less commenting your code needs, the better that code is. In most cases a simple one-line explanation of what this segment of code does is far more important than providing a full logical breakdown of your implementation. As your code base gets larger, these succinct comments become valuable not just by serving as "functional chapters" of which sections of the app handles what functionality, but it also makes the complex logic that requires more thorough commenting stand out, highlighting their importance and preventing them from becoming noise (and eventually, tech debt).
It's important to reiterate: coding time is lost not in the writing of code, but the reading of it. So if you've got code that is perfectly readable as it is, why add another 20-30 seconds of reading time having a comment that says the exact same thing as the code itself?
Balancing Reusability and Specialization
The one universal truth of software development is this: the best code is the code you don't have to write. This is used as an axiom to the benefits of reusability and "dry" coding styles. Reusable code promotes efficiency, keeps consistency across the code base, and prevents developers from needing to solve the same problems over and over again. And you'll be happy to know that I completely endorse this line of thinking when it comes to coding...with some caveats.
There is a point where reusability for its own sake leads to such excessive abstraction that the system becomes needlessly complex. I went through a period (and have seen others do the same), when adapting to component based frameworks where every single part of every single app was a component. The result? Having to chase bugs through several times the number of files, because all of these components were effecting each other in the implementation, making the actual solution (which only took a line of code to implement!), take significantly longer than necessary.
The Importance of Consistency, and Adapting to Inconsistency
In a production environment, consistency in coding style and formatting is paramount. It streamlines collaboration, reduces cognitive load when switching between different parts of the codebase, and generally leads to a more professional and manageable project.
That said, I believe there's significant value in developers experimenting with different coding styles and patterns in their personal projects or during the learning process. This experimentation broadens a developer's perspective and enhances their ability to understand and work with diverse codebases.
I've put forward what may be some controversial opinions, but my views here are in-line with what I think is standard in the industry: cultivating a particular style in coding, and maintaining it across a code base, is vital to any team-based development. Anyone from any part of the project should be able to look at your work and understand its structure, and once they're familiar with its functionality, add to it in a way that's unobtrusive to future contributors.
Unfortunately, there is not one universal "best" style to adopt. This requires developers to experiment and explore in their personal projects and education. I consider this the equivalent of familiarizing yourself with other dialects of your native language, even if you don't use them in your daily life. It will make you more fluent when communicating, and again, keep you writing code instead of reading it.
Testing: The Safety Net of Good Code
As codebases grow in complexity, the importance of formal testing cannot be overstated. With each new feature, the number of potential edge cases can increase exponentially. A comprehensive test suite acts as a safety net, allowing developers to catch and fix issues before they make it to production. This is the part of the code base where I think reusability is the most important.
We've all had experiences where a section of code you haven't even touched suddenly breaks when you implement new functionality. And sometimes things as simple as renaming a variable can cause a cascade of new and challenging problems. Squashing these bugs is important, but I think adding them to your testing suite is the real value. Being able to automate every issue you've seen before can let you know incredibly early if that issue is coming back before you start building more production on top of it. And having a robust test suite to recapture old bugs is several orders of magnitude faster than manually chasing down broken code.
Conclusion
Everyone has opinions on what makes code good or bad, but I believe most people would agree that no matter how much you enjoy writing code, reading it is a necessary headache. Therefore, good code is code that you can read quickly, that communicates its functionality clearly, and that can be easily understood and expanded upon. Software very rarely becomes less complex, so its our job as developers to remove the hurdles to understanding that complexity for those that we work with, ensuring that our code stands the test of time.
What are your thoughts? What makes "good" code?
Top comments (0)