While working in the field of software engineering or software development for several years, we come across some acronyms or say technical jargons which we are totally unaware of.

We often listen to these in the technical discussions with your Architect or in the Code Reviews.

We also been told to follow clean coding practices or principles, follow some good practices or coding and design standards if given.

Here, in this blog, I will try to make you aware of some acronyms which are used more often in the industry while working. I have tried to keep it short and concise. People often get bored reading lengthy posts. :P

I have tried to make this easy-peasy for you so that you can remember them and implement in your day-to-day activities. Also, to help you be the smart guy in the room !! ;)

One of my favorite lines I came along is :

Code represents knowledge. By giving meaning to certain parts of the code, we are identifying and labeling that knowledge.

DRY/OAOO

DRY stands for Don't Repeat Yourself and OAOO stands for Once and Only Once.

These are self explanatory which says that you should avoid code duplication at all costs.

• In code, whatever it may be, should be written only once and in a single place.

• If there are any modifications to be done in the future, they should be done in that specific location ( here location means class or function or module ).

• Failure to do so is a sign of poor software design.

• Code duplication affects maintainability. Some of its cons are:

1. It is error-prone.
2. It is expensive.
3. It is unreliable.

YAGNI (You Ain't Gonna Need It)

• Sometimes, while developing a software we think of the future enhancements or requirements and try to make the code future-proof. As a result, we create solutions that are complex or create abstractions which are hard to maintain.

• After sometime, we get to know that these requirements are not required at all and we end up piling the unnecessary code. And sometimes, due to this the code which we actually need for our current requirements does not work at all.
  Feels like a waste of time right ?

• YAGNI principle tells us that , do not try to perform futurology or future-proof code.

• While designing your system, make sure that you are only addressing your current requirements in such a way that it can be easily modified later on.

• Do not over-engineer !!!

• Do not develop or design more than what is necessary.

KIS/KISS (Keep It Simple / Keep It Simple, Stupid )

• You may have come across this term many times. This principle very much relates to our previous point.

• This principle says that implement minimal functionality which correctly solves your problem.

• In other words, satisfies your current requirement and does not complicate it more than what is necessary.

• This principle is what we need to keep in mind at all levels of abstraction. While designing a microservice on a higher-level or defining a function or writing a particular line of code.

• At a code level, it simply means using the smallest data structure that fits the problem statement.

EAFP/LBYL

• EAPF stands for Easier to ask Forgiveness than Permission while LBYL stands for Look Before You Leap.

• EAPF tells us that we write our code so that it performs some execution directly. If the code does not work, we will catch the exception and try to execute some corrective logic on the except block.

• We often see this approach used by many developers.
  It goes something like this.
  

try:
    # your running code
except SomeMeaningfulException as e:
    # corrective actions

• LBYL principle is exactly opposite to that of EAPF.

• In this approach, we check what we are about to use or perform.
  For example, before opening a file in the program, we want to check if that file actually exists in the given path or not.

• Both of the principles makes sense in a particular code or action. EAFP is more acceptable as it is easier to pick at the first glance.

• I would suggest to pick up the EAFP when in doubt.

So these are the most common principles you will come across while developing a software and we should take utmost care that these principles are being followed.

Some of them you make come across while implementing Design Patterns in your system.

I hope am able to deliver this topic in a simple and in an effective way. Feedbacks and suggestions are always welcomed.

Happy Learning !!!