Keeping code clean and the WTFs down!
As eloquently noted by Robert Martin in his book Clean Code, the only valid measurement of code quality is the number of WTFs per minute.
With me being a Junior Developer, code reviews are a must and these happen at least once a week here at Twilo, to help me progress and become a better developer – alongside ensuring the front-end development work we’re producing is the best it can be.
Spaces before braces is a little term that came about in one of these reviews. When we were looking at how ‘clean’ my code was, the senior web developers noticed that within my CSS and PHP code I was missing the spaces around the braces ‘{ }’.
The result? I was slowing both my co-workers and myself down when trying to read my code as spaces were missing which made it hard to follow and understand what was going on within the code.
Functional Code Doesn’t Mean Clean Code
Although you could say my code was correct and functional, it was far from ideal. If you have read ‘Clean Code’ by Robert C. Martin, you will have noticed I have broken one of the understandability tips:
“Be Consistent, If you do something a certain way, do all similar things in the same way.”
Is this a major issue if I worked on my own? No.
Will it affect me being able to work in a team and progress as a developer… Hell yeah!
Code Naming Convention
I was missing spaces. Although small, this can cause quite a big issue. This however was not the only criminal offence I had committed. I had also broken one of the naming rules:
“Choose descriptive and unambiguous names.”
This one was quite embarrassing as I naively thought I wasn’t too bad at naming. This was not the case as when going between the HTML, CSS and JavaScript code and being asked what this class does and what does that ID do, there was some confusion.
A few I was not too sure on. I had used a cryptic name which gave no description and… left no comments behind to assist (Another rule broken… it’s only been a week and I’m already 3 deep).
Keeping Code Clean
Just from that one review and consistently saying, “spaces before braces” as I write my code, and asking myself:
“If I come back to this in a year will I know what this does?”
“Where will I go if something does break?”
I have been able to improve my overall speed as not only can my co-workers actually read my code and understand what’s going on when I ask for help. I can also easily remember and reuse the classes and functions, without having to keep going back and forth trying to find the correct one.
The Benefits As A Front End Developer
When we look at the bigger picture, the developers within a company are a team, and if you have ever been within a team, you will know players come and go but processes and plays remain the same (on a basic level, let’s not get too technical).
What does this mean? Well if each developer kept their code in a different format to the next, in a couple of years’ time when someone needs to maintain that code, the time taken to maintain this is greatly increased. Before starting anything, they have to read and understand what’s going on under the hood.
However, if each developer followed a set of rules – within a few glances of the code – the bugs would have been cleared (we hope).
Lesson Learnt
Let’s be honest writing code can be hard work, never mind consciously having to think about making it ‘clean’ but as time goes on, like with any skill, it becomes easier.
Let’s not forget, programmers are authors and the target audience are humans not the computer. We should always be striving to improve the quality of our code even if it is something as small as making sure we have spaces before braces.
Even though I am located in the UK, the boy scouts of America have a simple rule that describes this in a few words:
“Leave the campground cleaner than you found it.”
The same rule applies to programmers. Always leave your code and the code you have checked cleaner than it before you opened it…it helps to reduce the WTFs/minute.
