Popular Acronyms

Published: 19 March 2021 in: #acronyms

Reading time: 3 minutes

Welcome to my third post.

I must admit that I start to enjoy writing more than ever before and I hope I'll keep momentum.

This time I'd like to focus on acronyms that are commonly used in software engineering. Most likely you already develop using some of the principles that are represented here without even being aware of it.

There are quite a few acronyms commonly used in software methodologies. Some less serious than others (eg. HDD - Hype Driven Development) but in this article, I'd like to focus only on the following 4:

Y.A.G.N.I., K.I.S.S., D.R.Y., & S.O.L.I.D. Knowing those will help you not only write better code but also during the interview process where you might be asked to decode either the entire shortening or particular letter.

Do not confuse acronyms with abbreviations as some sites/articles do as those two are quite distinct.

Abbreviation form new words eg Dr for Doctor
acronym typically contains a set of initial letters eg. ASAP As Soon As Possible

Y.A.G.N.I - You Ain’t Gonna Need It

YAGNI is a principle of Extreme Programming (XP) that sets that a programmer should not add functionality until deemed necessary. In my view, this principle should go before the K.I.S.S principle where you should think twice if you really going to need certain functionality if yes keep it simple.

K.I.S.S - Keep it Simple, Stupid

Prefer starting with simple solutions as those are less time-consuming to write and easier to maintain. If the function is too complex you might notice that some of its body is not even being used by your app. Therefore it's better to keep things simple and develop them within time.

This rule also applies to processes within your organization. When working in a team try to avoid Complexity Bias by making things more complicated than they need to be?

To quote classic:

If I had more time, I would have written you a shorter letter.

D.R.Y - Don't Repeat Yourself

It's one of the most important rules in the process of developing software. Avoid writing the same logic in your code multiple times. It is very natural and hard at the same time.

We have functions, classes, methods and other methods to achieve our goal by making our code modular and reusable. However, we are sometimes lazy and not willing to refactor already created function. Instead, we prefer to just duplicate logic and simply give it a new name.

You should also be aware of some common gotchas when applying this rule. For example, if you find 2 pieces of code that look identical - it's not always an indicator to merge them into one. When analysing ask yourself the following 2 questions:

Do these 2 functions describe the same business model?
Are those 2 pieces of code will be changed always at the same time?

If you get Yes for both questions then you can go ahead and merge those into one.

Otherwise, it's better to keep them separate to make your code more flexible and depended on when making changes to business model.

S.O.L.I.D

It is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin, popularly known as Uncle Bob.

S - Single responsibility principle (SRP): a classes/method should be responsible for one job only
O - Open-closed principle (OCP): Our code should be written in a way that allows us to extend it without the need of modifying it.
L - Liskov substitution principle (LSP): Functions that use pointers or references to base classes must also be able to use class objects that inherit from parent classes without knowing exactly what those objects are. One of the classic examples of this principle is a rectangle having four sides. A rectangle's height can be any value and width can be any value. A square is a rectangle with equal width and height. So we can say that we can extend the properties of the rectangle class into square class. In order to do that you need to swap the child (square) class with the parent (rectangle) class to fit the definition of a square having four equal sides but a derived class does not affect the behaviour of the parent class so if you will do that it will violate the Liskov Substitution Principle.
I - Interface segregation principle (ISP): This principle advises software designers to avoid depending on things that they don’t use. Avoid providing a class with many methods where the user in fact will use only one. It's better to create more but smaller classes then one massive one. This way it will be easier to break up our code into smaller components.
D - Dependency Inversion Principle (DIP): Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but should depend on abstractions. To not be mistaken with Dependency Injection as both are different concepts.

Useful resources:

If you liked this article, please share it on Twitter.