For more content like this, follow ButterCMS on Twitter and subscribe to our blog.
Every day, millions of developers write code and labor through code reviews in hopes of contributing good code to the software they're working on.
But what is "good code"?
With new frameworks and programming languages being released every month, it's easy to forget about the fundamental qualities that make for "good code". Sometimes it can just boil down to personal preference or documented conventions, but what else?
We thought it'd be interesting to ask some CTO's how they define good code:
Jerry Hill, CTO at Authentic (@AuthenticDgtl)
Jerry Hill has been working with software since 1996, after graduating from the University of Southern Missisippi. Today, he oversees the technical operations at Authentic, a full-service digital marketing agency that works with an array of Fortune 500 companies.
“There’s not one thing that I can pinpoint that defines ‘Good Code’. In fact, I like to think there are five factors that should always be considered when building code:
- Whether you’re building a product or setting up an implementation of a product, it’s critical to understand what the code will be used for and what type of development is necessary. Application development and implementation development are very different, so it’s important to understand the desired result.
- You always want to make sure you avoid doing things that can create future upgrade problems or that will impact future cycle changes.
- Be pragmatic in everything that you do. Of the five factors, this is probably the most important. I always try to grasp a full understanding of the requirements and priorities outlined by the client to make sure that the code we build reflects the highest valued pieces.
- The code should read like real language. Development should always be writing code with the people in mind that will be reading it after them. So, it’s important to use strategies where you can reference variables as nouns and methods as verbs. This helps cut down on needing tons of comments and complexity in management.
- Follow through. The code must be well tested to ensure that it can stand the test of time.”
Alex Malureanu, Co-Founder and CTO at Ascendia (@AlexMalureanu)
Since Co-Founding Acendia over a decade ago, an eLearning platform, Alex Malureanu’s main role has to develop new eLearning and mLearning products for broad audiences.
“Good code is not only about getting the task done. It’s about writing something that permits easy modification later on. After all, in today's world, we need to modify code as much as we need to write it.
That's why, for our team, one of the most important traits of "good code" is readability. Even if it's not using the most elegant approach or it's buggy, the fact that you can easily read it and understand the approach of the developer makes it easier to modify, build open and delete where necessary. Â
With readable code, you can find faster a better approach or bugs, improve it more easily and make it more elegant. Writing readable code will also improve other important aspects of it: speed for the end user, reviewability, low error rates and so forth.
It is not a time consuming task and it will payback when you will read it only once to understand it, rather than reading multiple times bad code.
Good code should also explain itself to anybody trying to read it, and this can usually be done by sufficient naming, structure, directionality, and so forth.
Bad code, on the other hand, always has signs of duplication or is superfluous in nature, making it difficult (and annoying) to read.
Alas, good code is not always void of redundancy or confusion, but it should at least keep such chaos to a minimum.”
Lauri Tunnela, CTO and Co-Founder at Paranotek (@WorldFlix)
Lauri Tunnela has over 10 years of IT experience, and now works on developing Paranotek, the cyber security and privacy software.
“First of all, I always recommend following the coding standards and conventions of whatever programming language is being used. This may sound like obvious advice, but many developers go wrong here.
By following the the pre-set standards, code will stay clean and readable, making it easy for anyone to read it or produce completely new code on top of it. If you start to deviate from those coding standards, you make life difficult for anybody collaborating with you.
Most of the IDEs support code linters which will actually tell a programmer if they are not following the standards specific to a language being used. Also, some IDEs even automatically reformat code in case it is badly formatted. I’ve found those tools to be very helpful, but I always recommend that developers should try their best to learn from those corrections, instead of just relying on them totally.
Secondly, when coding standards and conventions are being followed, it is very important that everyone in a project or company follows suit. The last thing you want is everybody coding in a slightly different way.
Thirdly, even if everyone is following the same standards and conventions, this does not guarantee the quality of the code. Before any coding takes place on a major project, the developers should come together to actually determine what is it that is being coded. After that has been determined, the next thing is to plan the fastest (and most creative) way to produce the actual piece of code. After a plan is made, programming work can begin with everybody on the same page, so to speak.”
What we've learned
Code should be written for humans, not just for computers.
What’s your definition of good code? Let us know in the comments section below.
 And if you liked these expert insights, check out our article about managing deadlines.
This was originally posted here.
Top comments (6)
Good code begins with good design and then makes the structure of that design obvious and well-documented.
Good code makes clear decisions about stylistic tradeoffs and sticks to them. It doesn’t wander too much in it’s conventions.
Good code empowers it’s readers to reason about it.
Good code disappears and lets you think about the stuff it’s describing.
i like this sentence.
From a boy using sucking English.
We read exponentially more code than we write.
Clean Code by Robert Martin is a really reference for good code, in my opinion.
Great article sir Roger! :smile:
No one of those guys said "SOLID" - which might be the proper answer to that question.
I like yo write my code in a way that doesn't require comments to explain everything. I'm really happy that a similar practice showed up on this list. Thanks for writing this!
Thanks for posting this Roger. This is great stuff.