Programming Principles

Programming principles encompass a set of best practices and rules that dictate how code should be
structured, organized, and written. They provide a framework for developers to follow, allowing them to
create high-quality code that is easy to understand, modify, and debug.

The significance of programming principles lies in their ability to improve the overall quality of the
codebase. By adhering to these principles, developers can ensure that their code is robust, scalable, and
resistant to common programming pitfalls. They also facilitate collaboration among developers by
promoting code consistency and readability.

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. 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 “ 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 “Keep It Simple, Stupid “ 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 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)

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)

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.

The term “premature optimization” describes devoting a substantial amount of time and energy to
project optimization before it is visible if such optimizations are actually advantageous or essential. It is
frequently linked to early in the development process performance gains in non-critical areas. “Pre-
optimize” refers to trying to increase something’s efficiency or optimize it before it’s absolutely necessary
or before all of the possible advantages and disadvantages are known. It emphasises the significance of
time and well-informed decision-making in optimisation attempts, which is consistent with the idea of
premature optimisation.

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

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.