How to Code, Better!
Description: This blog is about writing code which is readable, maintainable and developers friendly.
Boy Scout Rule:
There is a rule in scout, “Always leave the field better than you found it”. When you find a code, improve it the best way you can for other developers. Just make sure it is working when you leave it. 😅
Think about the Problem:
When you are thinking about solutions to a problem, don’t just think about solutions but also problems.
If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. ~Albert Einstein
Sometimes, the Solution is very simple. We just need to see the problem from a different point of view. Sometimes, “Out of intense complexities, intense simplicities emerge”, said Winston Churchill. Try to find simplicities out of complexities.
Know your Code:
There is a Golden rule saying, “If it works, don’t touch it”. Yes! But It will not make you a good programmer. I will say, “Know thy Code”. When you are coding, even when are just copy-pasting from Top Answer of Stack Overflow. Try to figure out how the code is working and How can you reuse it. Don’t be a ctrl-c, ctrl-v bot. Read the code, before hitting “ctrl-c”.
Keep it Clean since Start:
From the very beginning of the code, try to follow all instructions and the code structure you decided on for your app. It is easy to keep it clean from start instead of coming back and removing the mess at the end. Use tools like prettier and eslint. They will help you in following rules all along the development.
Use SOLID:
Try to use the SOLID principle, these things will help you to make your code cleaner, maintainable, reusable and readable.
S: Single Responsibility for each function/component
O: Open for enhancement/Close for modification
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle
Here is the link to a blog From Okan Yenigün for reading more about SOLID.
Design Patterns:
Design Patterns may feel overworked at the start but they can save you from big troubles in the long run. It might feel overwhelming at first but it is a good thing and will defiantly make your code better.
Reduce Complexity:
When you get a code, try to reduce complexity as much as you can. Keep your code as simple as possible. Try to comment when required. Use indentations and appropriate variable names.
Split into Function:
Split your code into functions, it will not only reduce the complexity but also make your code reusable. A function should be no more than 20–30 lines.
Don’t Do it alone:
Don’t code alone, peer programming is better than Code Reviews. Maybe the problem you are facing is faced by your coworker and fixed successfully. You should share your problems with coworkers and ask them when you face an obstacle. Communication is the key to teamwork and teamwork is the way of dream work.
Multitasking makes you stupid:
Multitasking feels like you are working hard but in reality, it reduces the efficiency of working by 10–20%. It’s more than that of working while you are high. When you working only focus on one thing and leave the other unintended. Relax and don’t overuse your brain. It's a marathon NOT a splint (Unless you are a Hacker).
Better Less, But Better:
Always code better, Quantity comes after Quality. When you are coding make sure your code gives a better solution to the problem. Solve one problem, one day but make sure. You give the best of yourself to solve the given problem. Don’t forget to Google, there are high chances that someone on Stackoverflow already has solved the problem for you. Take a look at the code in the following image, and choose your side.
THINK Before you Code:
Think before you leap ✔️
Think before you code ✔️✔️✔️
Before you sit and start declaring variables. Write code (for complex problems) on your paper, reduce lines of code and variables used, and decrease the Big’O (time complexity) of your solution then you can start coding and split it into functions to reduce code complexity.
Avoid Premature Optimization:
You can write a code with BigO(1) that does nothing and you can write BigO(logn) that sort an array. I think “BigO(logn)” is better.
Before you start optimizing your code, make sure your code does, what you are expecting it to do. Avoid Premature optimization, It will only increase complexity for you and nothing else. Firstly, solve the problem, then solve it in a better way.
Self Documented Code:
The best Documentation for any software is its Source Code. And a good code is self-explanatory. Write a code that is understandable by any beginner. The Code is like Joke If you have to explain it, it’s not good enough.
Use the appropriate variable names, use comments when required and keep it simple for you (from the future) and your fellows.
Accept you are wrong:
Last but not least, if you write a code that doesn’t do what it suppose to do then you must accept that you are wrong. We all make mistakes, the best thing is to accept them instead of trying to prove yourself right. Arguing to a dead end, because we all know that at the end of the day, it’s you and your team that has to fix it. Instead of wasting your energy on proving yourself right. Try to do the right thing.
FINAL WORDS:
I have all these things written in my notebook and I go through all these points before starting my work day so, when I am working I can do things better and more effectively for myself and my fellows.
I am looking forward to your suggestions and comments, to improve my blog.
#Happy_coding
