Throughout the years of my dev career, I have noticed some patterns at developing which if not followed to a T, could be a hindrance to your project. These patterns apply to the object-oriented paradigm, so I don’t know if these could work in a functional, imperative, etc. paradigm. Here are some of them:
KISS (Keep It Simple Stupid): You know, sometimes you can get the urge to implement something that the client hasn’t even thought or you implement that new feature you have been thinking of in your passion project, but you have to cut that idea short. This principle means that you only need to implement what has been decided, not implement something you foresee that the project needs. This helps to have an understandable and easy to develop codebase, plus, you can apply this in UX or other design areas.
SOLID principles:
S (Single Responsibility): A class should only have one job. If you have a class like Vehicle and methods like StartEngine, Brake, etc. you don’t want to “build” a car inside this class. You should leave that concern to a parent class or an interface.
O (Open-closed): Objects or entities should be open for extension but closed for modification. Following the previous example, you should extend the Vehicle class for a Boat class, Car class, Bicycle, etc. you don’t need to change the base class for that, doing otherwise would create bugs in the future.
L (Liskov Substitution): Every subclass or derived class should be substitutable for their base or parent class. A child class should run the same methods that the parent class has and add its own functionality that should change how the parent class behaves.
I (Interface Segregation): A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. This means obfuscation and segregation, if you want to add more action to a vendor API or class, you should implement their interface to create another action and you don’t need to create an instance of their class to use it.
D (Dependency Inversion): Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but should depend on abstractions. Actions should be performed in a high-level abstraction and defined in a low-level abstraction, so that a class does not depend on another instance of a class, avoiding a dependency circle.
DRY (Don’t Repeat Yourself): This one is simple and I think is one of the most common tropes a beginner programmer can have. DRY means don’t repeat sections of your code in other classes, methods, etc. If you realize that you need a specific abstraction in two different classes, try to divide that code into a new class or interface, that way you can have only one definition of your code and not two same pieces in other places.
Here is one of my own, CYD (Check Your Debug): I learned this the hard way when I was a student at University, don’t try to outsmart your IDE or guess what can fix it. See the error, copy and paste it to Google or StackOverflow, read it carefully and implement the solution. For example, don’t try to assume that the computer shouldn’t display an error when you declare a nonexistent member in your declared object. Maybe you should declare an instance of your class or create that member.
