We are not living in the Stone Age any more, we are social human beings and we should be also social engineers. It was long time ago when a project was a one-man show, so we have to learn to collaborate, we have to learn how to work in mixed-skills teams and how to share ideas and solutions in order to have a successful life as code writers.
According to Tudor Girba1, as developers we spend about half of our working time reading code. Why reading code? Because the current code bases are growing every day, and with each task we have to implement,we will end up reading code more than actually writing it.
This article is a lobby for writing better code in order to make our life easier and to improve our own output.
One of the definitions of quality is "A combination of quantitative and qualitative perspectives for which each person has his or her own definition; examples of which include, "Meeting the requirements and expectations in service or product that were committed to" and "Pursuit of optimal solutions contributing to confirmed successes, fulfilling accountabilities". In technical usage, quality can have two meanings:
The intention of this article is to convince you, the reader, that it is better to choose the optimal approach in your work, rather than just aim to meet the requirements. In this case, I am talking about the code you write and its continuous improvement, as not only will it help you grow professionally, but it will also add more value to the work that you produce.
I will focus just on some of the metrics that define the quality of the code, as the list is long and in many projects we are only interested in improving a few of them. For example, in a speed sensitive application, we might not consider code readability so important, however, in very big applications, with lots of functionalities, that need to be easily maintainable, code readability is crucial.
http://4.bp.blogspot.com/-y_lWkRMgj14/TbFh9Z-QVvI/AAAAAAAAA20/XX9gGa74ZQ8/s640/wtf.png
So here are a few of the metrics that could help you understand the quality of the code:
There are several aspects to be brought into this discussion, and definitely an important part of metrics is meeting the requirements. Software is there to solve problems but not to cause more problems. So make sure you understand the requirements when you start working. Both functional and non functional.
Check regularly to see that you are going in the right direction. Depending on the style of work adopted in your project, demoing the product often and asking for feedback can only keep you on track and can decrease the costs of having to do big changes later.
Another important aspect that we have to take into consideration is that code has to be readable. This is becoming more and more important as the pieces of code that we write, or the amount of code lines we are exposed to as developers is increasing every single day. If this aspect is catered for, then reading code will be easier, and it will make everyone's lives better.
The fundamental theory of Readability3 says: "Code should be written to minimize the time it would take for someone else to understand it." Keep in mind that 'someone else' can be you.
Just think about the number of times you had to fix a bug two months after you had written the code, and you had to navigate through the classes to find the exact location that dealt with the logic you wanted to fix. It helps if you document well your work, name properly the objects you work with and do a clear separation of concerns.
When talking about maintainability we have to take into consideration the life span of your product. While some applications are rewritten every 3-4 years to catch up with the technological progress, others will be there for 20 years or more. And yes, nobody wants to touch those monsters, but we sometimes have to get dirty first in order to shine.
So we have to code responsibly, keeping in mind the actions that will be needed later to do any kind of changes. As we don't always know what lies ahead, we have to adapt.
Refactoring is the process of rewriting parts of the code to bring it up to date with the latest architecture or the latest technologies or simply refresh the code. It is a way of updating the code. Take time to re-factor code, as it can bring multiple benefits both to the project that is refreshed and the developers involved, who can learn a lot in the process.
And remember an old saying:
https://i.stack.imgur.com/TZrwp.jpg
Of course, there are other metrics that matter in writing code, however, the aim of this article is to make a point of caring about what we write and not to exhaustively present the good and bad practices in writing code. That being said this list stops here.
http://www.akaita.com/media/xkcd-code-quality-2x.png
There are little steps that we can take every day to improve our output in terms of written code.
Asking for help is really efficient, as feedback from others can give better hints on the aspects you have to focus on for improvement. Also, others can see and read the code objectively. Here I will suggest a few improvement steps that we've tried in our company and that worked out nicely.
All the programming languages have coding standards. They cover a lot of aspects of the code, from naming methods and variables to usage of external libraries and to code arrangement in the page. Their purpose is to unify the way we write code, to help with collaboration between peers and make adjustments to a new project easier. But the coding standards are only valuable if they are followed.
Coding standards don't have to be necessarily valid for all the developers who use the same language, they don't have to be necessarily valid for all the developers in the company, but it is very useful to have coding standards in a project. It will make everyone's live easier if the entire project is written in the same style, making reading and understanding it easier.
You can either adopt standards from a big company4 or agree on your own standards inside the group. Agreeing and, what's more important - following standards, is a first step in adjusting better to the social way we have to develop nowadays.
A code review can be a formal process, when one or more developers check the changes implemented for a particular ticket by their colleague, before these changes make it in the master branch.
In many teams this process is standardized, however, a lot of teams have no code reviews at all.
A code review can be a good opportunity to learn and improve the produced code. To be helpful, the attitude towards code reviews has to shift from 'mandatory and annoying' to 'helpful and collaborative'. And even if there is no formal process for reviewing the code, we can always ask our colleagues to have a look and give us suggestions on how to improve it.
If a developer and a reviewer are not very attached to their work, a code review will result in a learning experience for both sides as seeing multiple alternatives and the reasoning behind different solutions can enlarge the experience of both the reviewer and the developer.
It is a process that everyone can benefit and learn from as long as we are open to feedback.
The static analysis tools help you notice potential issues that you might miss, they can check the code to see if it meets the coding standards, whether it is too complex or how much duplicate code there is.
Such tools as Sonar, Coverity, Checkstyle and others help to keep the code readable and maintainable. Some tools are paid, but there are others that are free and can be used by anyone to analyze their own code and help to improve it.
Don't get scared while the first analysis takes place, you might have a lot of issues in your code, even if you thought that the code is as good as it gets. Try to check every issue and ask yourself how can you do it better.
The result of such an analysis can be the beginning of a refactoring process, as it shows flaws in the current implementation, things that can be improved.
Why is testing your code helpful in improving it? I believe it is clear. However, there are multiple ways of testing code.
This paragraph refers to the entire set of tests you can perform on your code.
The wider your tests are the better the outcome. Unit tests are just a small piece in the puzzle. On top of the unit tests you have to add other functional and non-functional tests. Try testing your work as good as you can, using a combination of unit tests and automated tests, trying out as many scenarios as possible. Try putting yourself in user's shoes and look from that perspective.
Except the fact that you can find new bugs before anyone else, this will increase your trust to move forward.
Have you ever imagined going in a bank or a public institution and seeing the clerk dressed in a messy outfit or with messy hair? Or what would you say to a banker who just told you they misplaced some of your documents and now he or she cannot find them any more?
Somehow the code that we write is a major part in the output that we have towards the world. We should take care of it, as it is our business card, one of the things that represents us and sometimes it is the exact thing that will create the first impression.
It is up to each of us to decide what we want to show, but the code that just works or just good enough might not be what we want others to think about us.
We are what we write, so it is time to improve ourselves.
Tudor Girba - an advocate for reinventing the software development environment - see http://tudorgirba.com/
According to the American Society for Quality
'The Art of Readable Code - Simple and Practical Techniques for Writing Better Code' - Dustin Boswell and Trevor Foucher
by Adina Verzes
by Diana Costa
