Tips From Smart Contract Developer & Security Analyst Crash Bandicoot of Geode Finance
Art by Francezca Rae Airoso
What’s the Difference Between Good Quality and Poor-Quality Coding?
One may not understand the importance of code quality until their colleague comes up with a bad quality code. If you are on your own it won’t be that much of a problem if your code is somehow working. However, if you are working in a team, then things start to change. The most intuitional way to understand good or poor quality is by checking how fast you can understand that code. Because in real life, everyone needs to work with others’ code and to work on a code that someone else wrote, you need to understand it first. For understanding the code, good naming practices are really important. When you see a variable named like a function and a function named like a class, things become hard to understand. So it should follow good naming practices and the names should be self-explanatory.
Let’s pretend for a moment that we have an imaginary developer. Our developer will obviously assume that the code that (s)he will work on, written by a colleague, would work without any errors; so it should be well tested. Testing also helps other programmers to understand the functionality and how to use the code. Also, the code should run in a time interval that makes sense. The time it requires surely depends on the project and the aim of the code, but if it is taking longer than it should be, it is nearly the same thing as having some bugs.
Furthermore, quality code should be self explanatory of course but documentation and comments should be there too. This is to explain how to use and why things are done in the way that they are done. So now, our developer knows that it is working without a problem and already understands the code, but some other part of the project changed and needs some fixing to maintain the code. It should not be a problem to fix it, for a good quality code. If it is a good quality code, when you fix some part of the code, it should not break many other parts.
At this point, our developer is able to maintain the code. A couple of weeks later, a new request came from the client and our developer needs to add some new functionality. For the code to be considered a good quality code, it should be easily extensible. Adding new functionalities should be easy and should not depend on many other parts.
Summation of Good Code Vs Bad Code
If we write those as bullet points;
- Good quality code:
- Easy to read, naming practices are clear
- It is well tested (unit test will not be enough generally, integration tests are required)
- Runs in a time that makes sense
- Code is self-explanatory, not so complex, straightforward
- Well documented and commented
- Maintainable, not breaking other parts of code while refactoring or fixing a bug
- Extensible, easy to add new functionalities, and does not depend on many other parts
- Bad quality code:
- Hard to understand, bad variable names like one letter variables
- Buggy and not tested well
- Not stable run times or not finishes in the required time interval
- The code is too complex and not readable
- Not documented at all and if there are comments, only explains what is done, not why it is done
- Not easy to maintain, code is like spaghetti, when you try to fix one part other parts break easily
- Had to extend the functionalities
How Can Code Quality Be Effectively Measured?
You can measure code quality in 2 ways, one is by checking the things which I mentioned in the previous question, and another way is by checking the quantitative metrics. There are three methods which are; Halstead complexity measures, cyclomatic complexity, and weighted micro function points, you can click and check them deeper from the links. Although there are these metrics out there, if you just listen to the qualitative metrics from my previous response, that will be good practice enough. Those three quantitative measures could be overkill for your project.
What’s an Acceptable Trade-off Between Speed & Quality?
We can approach this question from two different points of view and I will explain both. These two points are a) speed of the program, and b) speed of the coding process. Firstly, in terms of the speed of the program, I can say that it depends on your requirements. You definitely should not try to optimize anything you do not need to optimize.
For example, writing your code in Assembly language for your website’s basic calculations to optimize does not make sense in terms of speed-quality trade-off. Since many other developers will go over that code and it will be a pain to try to follow the data inside the registers and so on. But if you are writing an application on a board that will be maintained really rarely and that you really need that speed, then it may make sense to sacrifice that readability and maintainability.
When we come to the speed of creating the program, to create your project, sacrificing quality really does not make sense at any point since it will cost you much more time in the long term. So always try to write the code with good quality, instead of writing in 5 months, code it in 8, but believe me you will lose much more than 3 months while trying to debug and maintain your code.
What’s the Best Way to Ensure Code Quality?
The first thing that I will recommend is to use a version control tool like GitHub. And also make sure that no one can push any code directly, even the best senior programmers can sometimes miss these kinds of quality checks. Reviewing and refactoring before merging any kind of code will help you a lot and save a lot of time.
Other than that, you should always ask the question, “When I open this code 2 months later, can I easily read this code?” If you cannot read your own code 2 months later, no one can read it. So reviewing is the best way to ensure code quality. First, review yourself and then let others review your work so that you can catch mistakes and bad practices which are done while writing the code.
The main thing I’ve seen while working as a developer and security analyst is that developers are always afraid of writing and refactoring their code. I saw this both in small, fast pace start-ups and big corporate companies. Do not hesitate to write your code from scratch, again and again, 2 times, 3 times, 4 times… Keep improving your code.
If your architecture is not allowing you to extend your code and you need it, change your architecture and rewrite the code. If there is another programming language that may help more and make things easier and clearer in terms of code, go for it and start changing your codebase. It may seem like you are losing time, but actually, you are gaining much more in the long term. Doing these things will help your code improve greatly and you’ll be able to see the difference if you keep track of both to compare back-to-back.
