Clean Freak
You may have been coding for a while now, but would you consider your code to be clean? When you are coding, do you take cleanliness into account (not relating to your surrounding btw, that's for another time)?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler
It may be tempting to forget about doing a cleaning round once your code is up and running as expected (I know it is). It can happen often that we forget how we have written things and just call it a day. You may have also already taken into consideration some of the most common tips while developing your masterpiece, but chances are that if you go about the code with a pair of judgmental eyes, you'll find several missing spots (pun intended).
One-man Band vs. Enterprise
When you are working on your side projects there is no implicit obligation of always committing the most impeccable code. You are there to have fun and learn a thing or two on your own time. You may have watched an awesome tutorial online and you couldn't wait to fire up your editor and create your own version of it.
That is fine! Coding on your own is mostly about having fun and loving what you do, but it may also be important that a couple of those online tutorials that you watch be about coding practices. Even on your own written projects, you will probably have a hard time figuring out what was done when you look back at it down the road.
Once you're in a work environment and the team is no longer comprised of you alone, things get a bit more serious. Several people are working on the same codebase, meaning that the code someone writes today may be in front of someone else tomorrow to add a new feature of some sort. This is when eyes will be directed at you and you'll most certainly be prompted to aid in understanding the what and the why of the code you have written.
Most clean code practices can be enforced at the time of code review before merging your changes into the project's main branch or even before it leaves the code editor, but, as I have experienced several times, many things can slip under the radar, only to be dug out later down the road.
The Tips
With all the context already given, let's jump right into some important tips for writing your clean code.
Tip #1 - Write meaningful names
This first tip is often memed about around the internet, with my favorite being the Narcos meme. It is joked that a developer may spend more time on deciding how to name functions and variables, than actually coding a given feature. Although somewhat exaggerated, naming is an extremely important aspect of writing clean code. It helps to enable the code to be self-documenting, meaning that if at some point down the future you look back at old code, it should be like reading plain English.
Tip #2 - Make the code readable
As with anything written, you will struggle to read it if it is all cluttered and doesn't follow any pre-existing formatting or agreed-upon structure. For example, you wouldn't be able to read code with ease if all of it was on the same line and had no spacing in between (this is an extreme example, but most parts of it are true).
Today, it is easy to fit your project with a linter that will automatically take care of that for you and check for inconsistencies. A linter operates on top of a set of rules that tell it how the code should be formatted and what syntax should be enforced. This is very common on larger teams where the code is verified before going to the main repository.
Tip #3 - Classes and functions are concise and follow the Single Responsibility Principle (SRP)
I believe everyone would agree that a small and concise block of code would be easier to read than its counterpart. Apart from that, segmenting your code in each of its individual pieces would ease unit testing since you are testing small bits at a time, so you know exactly the source of the bug, and the debugging process is accelerated.
Of course, there will always be a handful of functions that you simply can't keep on a lower line count. However, that's when following SRP will reap its benefits by enabling the ability to pinpoint the source of a bug since it would be the only class or function with the responsibility to commit that change. Also, by following this principle, you would have an easier time naming the class or function because it only has one clear, simple job (instead of 4 or 5 mashed together).
Tip #4 - Remove duplicates
Duplicate code is the recipe for disaster. if at any point in the future you need to go back and edit it, you are extremely likely to not know that the same logic is replicated somewhere else, and thus, this is how many bugs are introduced into your system.
Once you are done coding your awesomely new feature, be sure to go back and re-read what you've coded and look for duplicates. These can be hiding in different forms of implementation, so keep your eyes wide open looking for these. Once spotted, extract that piece of duplicated code into a new method, mostly likely a helper. In the future, when something needs changing, you can refer simply to that extracted helper method, making the changes cheaper to conduct.
Tip #5 - Review other's code
It is easy to fall in love with your own code and, as they say, love is sometimes blind.
Reviewing other people's code, the same as reading someone's book, helps you open your mind to new realities. It is easier to be judgmental of other people's property instead of your own, so you can gain some insights from your own evaluation of their code. Keep in mind that can be both on the positive side and on the negative, the idea is that you will slowly but surely pick up a more refined sense of what is clean code and therefore, begin implementing it in your own work.
Of course that if you are working alone and have no other co-workers code to look at, you can always wander around some random GitHub accounts and see what they are up to. There is even a subreddit where people review each other's work, check it out!
Now get out there and start coding a bit cleaner and don't worry that with time everything gets easier, just keep going strong!
If by chance, you enjoy what I write, you may also like what I have to say on my Twitter profile), come and say 'Hi! 👋'.