In other words – a little bit about development from two perspectives:
- code smells
- clean code
To make it be understandable for future generations, your code should fall within second one and you should prevent to have to much of first ones. Today I am going to show you how to make your code more friendly. In one of future posts I will get back with things, that you should beware of.
Clean code. Every developer dreams about meeting it on his career path during dozens of projects, but not every can preserve its sample principles. Let’s list the most important below:
- DRY – Don’t Repeat Yourself. As a developer you should beware of duplicating code or information within application. In other words: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. Antonym of DRY is WET and it stands for “Write Everything Twice”.
- KISS – Keep It Simple, Stupid. It should be written so simple, so even mentioned Stupid will understand what this part of code is for. Side note: after several years in huge project even creator of specific part does not remember, what it was about. Following one guy from stackoverflow:
//When I wrote this, only God and I understood what I was doing //Now, God only knows
- YAGNI – You Aren’t Gonna Need It. In other words – don’t write unnecessary code. If it will be needed in the future, you will write it then. It happens very often in the early phase of development of product, that concept changes and even if you meant well, you would have to drop a lot of code, because it is never used.
- SOLID – This one stands for 5 other principles:
- Single responsibility principle – Class should have one single responsibility. As in real life – you cannot vacuum with washing machine nor refrigerators.
- Open/closed principle – Your software should be extendable, but should not demand rewriting in the future.
- Liskov substitution principle – Object should be replaceable with its subclass instance without altering correctness of the program.
- Interface segregation principle – In other words, you should have dedicated interfaces instead of all general-purpose and big one.
- Dependency inversion principle – You should depend on abstractions, not on concrete classes. As my former team leader used to say: “Always code to interfaces”.
At the very end – remember to behave in harmony with “The Boy Scout Rule”, which is not programming principle originally, but helps to maintain teamwork:
“Always leave the campground cleaner than you found it.”