Posted by 
As a part of what we do at Geektrust, we give developers feedback on their solutions to our coding challenges. Naturally, we end up repeating the same feedback a lot because the basis of differentiating good code vs bad is the same. Sure, we factor in styles and preferences but the core aspects remain the same. This post will help future code submitters understand in depth what we look for in code. So here goes!
Let’s say you’ve developed a piece of software for XYZ company. You no longer work for XYZ. There is an important bug fix that needs to be done and a new person is assigned to the task of fixing it. He/She cannot draw his/her own interpretation of how the software is written and executed. A piece of code a computer can understand has to be predictable, given that it follows a programmed set of logic and conditions. It becomes very important for the person who is maintaining your software to understand and fix bugs or add additional features in the shortest amount of time possible.
However, sometimes we look at a piece of code we wrote 6 months ago and go, “did I really write this? Why would I write something like this?” To avoid such situations there has to be some basic set of principles to define good code.
The most important aspect of good code is that it works. Irrespective of how beautiful you think your code is, if it does not work or cannot be deployed to production then it is not good code. This also means it is performant. The execution of a piece of logic cannot take forever to determine a result. Good code that works is like an old car that still keeps running with very little maintenance bills every year.
Good code means there are components that can be reused. If there is duplicate code across functions/classes it might be a good practice to pull them out into a common util or a behaviour to a class that can be called from multiple places. How would this help, you may ask. If there is a bug fix it would be better to do it in one place instead of fixing it in multiple places and missing out on some because of duplicated code. Also, it makes it easier for someone to read smaller readable functions which have a single responsibility.
Good code should be able to express themselves. Just like a human emotion, by looking at the expression of the person we should be able to know if he/she is happy or sad or angry.
Good code follows a good set of naming conventions. Naming of variables should have a consistent pattern. How often do we come across variables like i, i1 etc. and wonder what they mean? Long functions are too difficult to read. They could be broken down into smaller meaningful functions with descriptive function names. A good practice would be to limit a function so that they can be read quickly. And limit your functions to no longer than a single screen height, so you don’t keep scrolling to understand what it’s doing.
At the end of the day, if your code can be understood and defined by a completely new person on your team the same way you would, then you’ve done a good job of writing good code.
Every time you take decisions — should I name it this way, should I create a new class or should I break this function into smaller functions — it’ll be good to pause for a second and think whether someone else will understand it.
So what do you think good code should have? Please share your views and questions in comments here, or write to us at devs@geektrust.in.
Related Links:
Geektrust Coding Help Docs
Blog posts on writing clean code
Coding challenges to showcase your Clean Code skills
About Geektrust
Geektrust is a platform for technologists to get the jobs they want, with the power of code. We believe that hiring should be primarily based on a person’s potential, and not just credentials like where you work, where you studied and how fast you can solve a DSA problem on a whiteboard. Hence, our platform is about showcasing how you write code in real life, applying the principles of clean code, and our coding challenges are designed to help you do this. No leaderboards, no competition. You compete only with yourself. And the bonus? You get feedback on your code, what is good, and what to improve.
When you apply to companies, you don’t get ghosted, and you don’t get rejected for silly reasons. Clean code is the #1 skill in demand today, and companies can’t wait to meet you!
Take a Geektrust coding challenge and find out for yourself.
Agree! Thanks for sharing these coding tips.
Great tips by a legendary coder!!
Thanks for the kitchen and bedroom example.
“we end up repeating the same feedback a lot because the basis of differentiating good code vs bad is the same” — curious on how much the reduction in human workload would be when the automated evaluation moves from a rules-based module to an AI tool?
thanks for the information
good one keep it up
thanks for sharing this tips