Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Martin Fowler, 2008
Bad code comes in many ways. Variables that don’t make sense or inconsistent naming, messy code, massive if-else chains, illegible formatting, hard to mantain, lack of tests, low cohesion, high coupling…
If you want to be a programmer, don’t settle for shortcuts and write code that is easy to maintain. How do you write effective code? You write good code following the programming principles.
1. Keep It Simple, Stupid (KISS)
Pretty simple. It’s easy to read and you know exactly what is going on.
Use clear variable names. Take advantage of coding libraries to use existing tools. Make it easy to come back after six months and get right back to work. Keeping it simple will save you the headache.
2. Don’t Repeat Yourself (DRY)
Plainly, it is not repeating code.
It’s a common coding mistake that it repeats over and over again. If you’ve ever copied and pasted code within your program, it’s not DRY code. When writing code, avoid duplication of data or logic.
3. Separation of Concerns (SoC)
The general idea is that one should avoid co-locating different concerns within the same piece of code. Break program functionality into separate modules that overlap as little as possible.
Simplify development and maintenance of software applications.
When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.
4. Single Level of Abstraction (SLA)
Each method should be written in terms of a single level of abstraction.
All statements of a method should belong to the same level of abstraction. If there is a statement which belongs to a lower level of abstraction, it should go to a private method which comprises statements on this level. Doing so will result in smaller methods.
5. You Aren’t Gonna Need It (YAGNI)
Always implement things when you actually need them, never when you just foresee that you need them.
It is a mantra from ExtremeProgramming that’s often used generally in agile software teams. It’s a statement that some capability we presume our software needs in the future should not be built now because «you aren’t gonna need it
5. SOLID
SOLID design principles help us create more understandable, flexible, and maintainable software.
This principle is an acronym of the next five principles
5.a Single Responsability
A class should only have a single responsability or a single purpose
5.b Open-closed
A software entity (class, module, function…) should be open for extension, but closed for modification which means you should be able to extend a class behavior, without modifying it.
5.c Liskov substitution
If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.
Subtypes must be substitutable for their base types.
Robert C. Martin
5.d Interface Segregation
Any client should be forced to depend on methods it does not use. Avoid fat interfaces.
Classes should never have to implement methods that violate the Single responsibility principle.
5.e Dependency Inversion
In object-oriented design, this principle is a specific form of loosely coupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.
The principle states:
- High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
- Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
5. Clean Code, Clever Code (4C’s)
Clean Code, Intelligent Code.
- Language in English, please. The control structures (if, else, for, foreach, switch, …), the functions (count, date, die, isset, empty, …) all are in English, therefore for consistency it is advisable that the name of our variables, classes and methods are written in English.
- Names should reveal intent and be short, clear, explicit, and descriptive.
- Methods or functions you develop should be small and only do one thing.
- Comments should not compensate for incorrect code.
- BoyScout rule, when you are going to make a modification on an existing method or class, take the opportunity to leave it a little better than it was.
- Protect your code with tests. Tests are your safety net.
You will notice the benefits of doing clean code from day one, and in the long run you will get a more robust, scalable and maintainable code.
6. Law of Demeter (LoD)
This principle divides the responsibility between classes or different units and it can be summarized in three points.
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
The Law of Demeter helps in maintaining independent classes and makes your code less coupled to get your application flexible, stable, maintainable and more understandable.