6 Principles Every Developer Should Know

Programming is similar to telling a story to another programmer, where variables are characters in your story, some of whom play their roles until the end and others who end up in the middle, different functions tell different parts of your story, and connecting all the classes or functions in a specific order can only complete the story. You want to write down the story in a specific order so that you can easily understand it and continue it by adding your lines from where it was left.

No matter how good a coder you are, your job in programming is not only to write code that works and produces the desired results, but also to write code that is maintainable, versatile, and easy to understand so that the person who continues or maintains your project can understand it and does not have to go through a horror story that gives him/her a nightmare.

Learning some programming principles and applying them to your code will help you become a better developer. It improves the quality of the code, making it easier for everyone to later add other functionality or make changes to it. Let’s go over some fundamental programming concepts and the advantages of using them.

6 Common Programming Principles

• DRY (Don’t Repeat yourself)

Duplicating data, logic, or functions in code not only lengthens your code but also wastes a lot of time when maintaining, debugging, or modifying the code. If you need to make a minor change to your code, you must do so in several places. The primary goal of “Don’t Repeat Yourself (DRY)” is to reduce code repetition. It specifies that a piece of code should only be implemented once in the source code. The opposite of the DRY principle is WET (“write everything twice” or “waste everyone’s time”), which violates the DRY principle if the same logic is written in multiple places. To avoid code repetition, you can create a common function or abstract your code.

• KISS (Keep It Simple, Stupid)

Nobody enjoys debugging, maintaining, or making changes to complex code. According to the “Keep It Simple, Stupid” (KISS) principle, most systems work best when they are kept simple rather than complex, so when writing code, your solution should not be complicated; that requires a lot of time and effort to understand. If your code is simple, other developers will have no trouble understanding it and will be able to continue working with it. So, always try to simplify your code by breaking a complex problem into smaller chunks or by removing any unnecessary code you’ve written.

• YAGNI (You Aren’t Gonna Need It)

If you write code that you will need in the future but not right now, your software or programme will grow larger and more complex. The “You Aren’t Gonna Need It (YAGNI)” principle states that “don’t implement something until it is absolutely necessary” because you are unlikely to use that piece of code in the future. While developing software, most programmers consider future possibilities and add code or logic for features that they do not require at the time. They include all unnecessary classes and functionality that they may never use in the future. This is completely incorrect, and you will eventually end up with distended code, as well as a complicated and difficult-to-maintain project. We recommend that all programmers avoid this error to save time and effort.

• SOLID

The SOLID principle stands for five principles: Single responsibility, Open-closed, Liskov substitution, Interface Segregation, and Dependency inversion. Robert C. Martin articulates these principles.

• SoC (Separation of Concerns)

Separation of Concerns, a complicated application is divided into sections or domains in principle. Each section or domain addresses a distinct issue or performs a specific function. Because each section is independent of the others, each section can be tackled independently, making it easier to maintain, update, and reuse the code.

In an application, for example, business logic (the content of the webpage) is a separate concern, and in a web application programme, a user interface is a separate concern. The MVC design, which divides data into three sections—model, controller, and what the end user sees—is one of the best examples of SoC since each section is handled separately. Data saving to a database has nothing to do with data rendering on the web.

• Avoid Premature Optimization

Optimization indeed helps in speeding up the programme or algorithm, but according to this principle, you don’t need to optimize your algorithm at an early stage of development. If you do premature optimization, you won’t be able to predict where a program’s bottlenecks will be, making maintenance more difficult. If you optimize your code at the start and the requirements change, your efforts will be wasted and your code will be discarded. As a result, it is preferable to optimize the algorithm at the appropriate time to reap the benefits.