Friday, December 27, 2024
Google search engine
HomeGuest Blogs7 Common Programming Principles That Every Developer Must Follow

7 Common Programming Principles That Every Developer Must Follow

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

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

7 Common Programming Principles

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 lines from where it was left. No matter how good a coder you are, in programming, your job is not just writing code that works and give you the desired output but 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

Programming principles are guidelines and best practices that help developers write clean, maintainable, and efficient code. Here are 7 common programming principles

1. KISS (Keep It Simple, Stupid)

Nobody in programming loves to debug, maintain, or make changes in complex code. It is very first principle, acronym stands for Keep It Simple, Stupid. The other famous alternate acronyms are 

  • 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.

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.

In KISS principal we neither want less nor more, we only want to have as much as is required. 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

Example of KISS (Keep It Simple, Stupid)

function mul ( a, b ) {      
return a*b
}




2. DRY (Don’t Repeat Yourself )

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 maintaining, 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.

Example of DRY (Don’t Repeat Yourself )

//Convert Two Temperatures From Fahrenheit to Celsius  before applying DRY principal

input far1 from user
input far2 from user
calculate cel1 = (fah1-32) *5/9
calculate cel2= (fah2-32)*5/9
print cel1
print cel2

//Convert Two Temperatures From Fahrenheit to Celsius after applying DRY principal

input far1 from user
input far2 from user
calculate cel1 = cal ( f1)
calculate cel2= cal (f2)
print cel1
print cel2
function cal ( fah ) {
cel= (fah1-32) *5/9
return cel
}






3. YAGNI (You Aren’t Gonna Need It )

Your software or program can become larger and complex if you are writing some code which you may need in the 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 they might 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.

Example of YAGNI

// If Programmer asked to write a Program to add 7 and 3
function (x,y){
return x+y
}
instead of this write what you have to told

function ( 7, 3 ){
return 7+3
}








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.

This principle is an acronym of the five principles which is given below.

  1. Single Responsibility Principle (SRP)
  2. Open/Closed Principle
  3. Liskov’s Substitution Principle (LSP)
  4. Interface Segregation Principle (ISP)
  5. Dependency Inversion Principle (DIP)
SOLID-Principle-in-Programming-Understand-With-Real-Life-Examples

SOLID Principles

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.

Example of SOC

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.

Separation-of-Concerns-(SoC)

Separation of Concerns (SoC)

6. Avoid Premature Optimization

Optimization indeed 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 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.
Law-of-Demeter

Law of Demeter

The Law of Demeter helps in maintaining independent classes and makes your code less which is very important in software development to make your application flexible, stable, maintainable and understandable.

Last Updated :
13 Mar, 2024
Like Article
Save Article


Previous

<!–

8 Min Read | Java

–>


Next


<!–

8 Min Read | Java

–>

Share your thoughts in the comments

RELATED ARTICLES

Most Popular

Recent Comments