Scribd
Upload
87 views

10 Coding Principles Every Programmer Should Learn: 1. DRY (Don't Repeat Yourself)

This document discusses 10 coding principles that every programmer should learn: 1. DRY (Don't Repeat Yourself) - Avoid duplicate code by abstracting common functionality. 2. Encapsulate What Changes - Encapsulate code that is likely to change in the future to improve testability and maintainability. 3. Open-Closed Design Principle - Classes, methods, and functions should be open for extension but closed for modification to prevent changing existing code. 4. Single Responsibility Principle - Classes and modules should have a single responsibility to reduce coupling and simplify maintenance.

Uploaded by

narendra_mahajan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
87 views

10 Coding Principles Every Programmer Should Learn: 1. DRY (Don't Repeat Yourself)

This document discusses 10 coding principles that every programmer should learn: 1. DRY (Don't Repeat Yourself) - Avoid duplicate code by abstracting common functionality. 2. Encapsulate What Changes - Encapsulate code that is likely to change in the future to improve testability and maintainability. 3. Open-Closed Design Principle - Classes, methods, and functions should be open for extension but closed for modification to prevent changing existing code. 4. Single Responsibility Principle - Classes and modules should have a single responsibility to reduce coupling and simplify maintenance.

Uploaded by

narendra_mahajan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

10 Coding Principles Every Programmer

Should Learn
1. DRY (Don’t repeat yourself)
Our first object-oriented design principle is DRY, as the name suggests DRY (don’t repeat yourself)
means don’t write duplicate code, instead use Abstraction to abstract everyday things in one
place.

If you have a block of code in more than two places, consider making it a separate method, or if
you use a hard-coded value more than one time, make them public final constant. The benefit of
this Object-oriented design principle is in maintenance.

It’s important not to abuse it, duplication is not for code, but for functionality.

It means if you have used standard code to validate OrderIdand SSN, it doesn’t mean they are the
same, or they will remain the same in the future.

By using standard code for two different functionality or thing, you tightly couple them forever,
and when your OrderId changes its format, your SSN validation code will break.

So beware of such coupling and don’t combine anything which uses similar code but is not
related. You can further check out the Basics of Software Architecture & Design Patterns in Java
course on Udemy to learn more about writing the right code and best practices to follow while
designing a system.

2. Encapsulate What Changes


There is only one thing which is constant in the software field, and that is “Change,” So
encapsulate the code you expect or suspect to be changed in the future.

The benefit of this OOP Design principle is that It’s easy to test and maintain proper encapsulated
code.

If you are coding in Java, then follow the principle of making variables and methods private by
default and increasing access step-by-step.

Several of the design patterns in Java uses Encapsulation; the Factory design pattern is one
example of Encapsulation, which encapsulates object creation code and provides flexibility to
introduce a new product later with no impact on existing code.

Btw, if you are interested in learning more about design patterns in Java and Object-Oriented
Programming, then you must check this Design Pattern Library course on Pluralsight. It’s one of
the best collections of design patterns and advice on how to use them in the real world.

3. Open Closed Design Principle


According to tho this OOP design principle, “Classes, methods, or functions should be Open for
extension (new functionality) and Closed for modification.”
This is another beautiful SOLID design principle, coined by Uncle Bob on his classic Clean
Codebook, which prevents someone from changing already tried and tested code.

The key benefit of this design principle is that a**lready tried and tested code is not touched
which means they won’t break.

Here is a Java code example which violates the Open-Closed Design Principle of Programming:

In this code GraphicEditor is tightly coupled with Shape, If you need a new Shape then you need
to modify already tried and tested system inside thedrawShape(Shape s) method, which is both
error-prone and not desirable.

Ideally, if you are adding new functionality only, then your code should be tested, and that’s the
goal of the Open Closed Design principle.

By the way, the Open-Closed principle is “O” from the SOLID acronym. If you want to learn more
about this principle, the SOLID Principles of Object-Oriented Design and Architecture course on
Udemy is one of the best resources to consult.

4. Single Responsibility Principle (SRP)


Single Responsibility Principle is another SOLID design principle and represents “S” in the SOLID
acronym. As per SRP, there should not be more than one reason for a class to change, or a level
should always handle single functionality.

The key benefit of this principle is that it reduces coupling between the individual component of
the software and Code.

For example, If you put more than one functionality in one Class in Java, it introduces coupling
between two functionalities, and even if you change one feature, there is a chance you broke
coupled functionality, which requires another round of testing to avoid any surprise on the
production environment.

You can further see From 0 to 1: Design Patterns — 24 That Matter course on Udemy to learn
about patterns that are based on this principle.

You might also like