7 Common Programming Principles That Every Developer Must Follow

If we give you a half story to continue it, how would you do that? how would you proceed further and add your own storyline there?

Firstly you need to understand the complete story, you will search for all the characters, their role in different chapters or part of the story, which characters you need to take till the end or which one has the role only for few chapters, you also need to understand how different parts of the story are connected with each other to tell you what’s exactly happening in the story.

7-Common-Programming-Principles-That-Every-Developer-Must-Follow



Programming is just like telling a story to a fellow programmer where variables are characters in your story some plays their role till the end and some end up in the middle, different functions are telling different parts of your story and connecting all the classes or functions in a specific order can only complete the story. To write down the story further, you want everything in a specific order so that you can understand the story easily and continue it adding your own lines from where it was left.
No matter how good coder you are, in programming your job is not just writing code that works and give you the desired output, your job is also writing a code that is maintainable, extensible and easy to understand so later the one who continue or maintains your project can understand it and he/she doesn’t have to go through a horror story which gives him/her a nightmare.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-Martin Golding

Learning some programming principles and using them in your code makes you a better developer. It improves the quality of code and later adding other functionality or making changes in it becomes easier for everyone. Let’s discuss some basic principles of programming and the benefits of using it.

7 Common Programming Principles

1. KISS: Nobody in programming love to debug, maintain or make changes in complex code. Keep It Simple, Stupid (KISS) states that most systems work best if they are kept simple rather than making it complex, so when you are writing code your solution should not be complicated that takes a lot of time and effort to understand. If your code is simple then other developers won’t face any problem understanding the code logic and they can easily proceed further with your code. So always try to simplify your code using different approaches like breaking a complex problem into smaller chunks or taking out some unnecessary code you have written.

The purpose of software engineering is to reduce complexity, not to create it.
-Pamela Zave

2. DRY: Duplication of data, logic or function in code not only makes your code lengthy but also wastes a lot of time when it comes to maintain, debug or modify the code. If you need to make a small change in your code then you need to do it at several places. “Don’t Repeat Yourself (DRY)” principal goal is to reduce the repetition of code. It states that a piece of code should be implemented in just one place in the source code. The opposite of the DRY principle is WET (“write everything twice” or “waste everyone’s time”) which breaks the DRY principle if you are writing the same logic at several places. You can create a common function or abstract your code to avoid the repetition in your code.

3. YAGNI: Your software or program can become larger and complex if you are writing some code which you may need in future but not at the moment. “You Aren’t Gonna Need It (YAGNI)” principle states that “don’t implement something until it is necessary” because in most of the cases you are not going to use that piece of code in future. Most of the programmers while implementing software think about the future possibility and add some code or logic for some other features which they don’t need at present. They add all the unnecessary class and functionality which maybe they never use in the future. Doing this is completely wrong and you will eventually end up in writing bloated code also your project becomes complicated and difficult to maintain. We recommend all the programmers to avoid this mistake to save a lot of time and effort.

4. SOLID: The SOLID principle stands for five principles which are Single responsibility, Open-closed, Liskov substitution, Interface Segregation, and Dependency inversion. These principles are given by Robert C. Martin and you can check about these SOLID Principle in detail.

5. Separation of Concerns (SoC): Separation of Concerns Principle partition a complicated application into different sections or domains. Each section or domain addresses a separate concern or has a specific job. Each section is independent of each other and that’s why each section can be tackled independently also it becomes easier to maintain, update and reuse the code.
For example business logic (the content of the webpage) in an application is a different concern and user interface is a different concern in a web application program. One of the good examples of SoC is the MVC pattern where data (“model”), the logic (“controller”), and what the end-user sees (“view”) divided into three different sections and each part is handled independently. Saving of data to a database has nothing to do with rendering the data on the web.

6. Avoid Premature Optimization: It is true that optimization helps in speeding up the program 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 know where a program’s bottlenecks will be and maintenance will become harder for you. If you optimize your code in the beginning and in case if the requirement may change than your efforts will be wasted and your code will go to the garbage. So it’s better to optimize the algorithm at the right time to get the right benefit of it.

Premature optimization is the root of all evil in programming.
–Donald Knuth

7. Law of Demeter: This principle was first introduced by Ian Holland in 1987 at Northeastern University. It is also known as the principle of least knowledge. 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 which is very important in software development to make your application flexible, stable, maintainable and understandable.



My Personal Notes arrow_drop_up

Web Developer, Technical Content Engineer

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.




Article Tags :

9


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.