Acronym you should live for

This post is a direct relation with my other post : “Custom Code is dead, long live Custom Code“. I am stating there that, sometimes, you have no choice to have custom code in your analytics implementation. However, it doesn’t mean that these custom code scripts should look ugly, quite the contrary. I will try to explain some acronym that I try to apply on my code so it looks better and is easier to maintain.

The content of this post is mostly coming from a book written by Mariano Anaya : Clean Code in Python
However, it can be applied to JS as well (and I would dare to say that JS projects I have seen are in greater need of that kind of principle).

It doesn’t mean that I am following these guidelines all the times, but I am trying to. It makes my project better and their maintenance easier. Also it feels like it makes me improve as a developer but also as an analytics person. it forces you to recognize pattern and find the most elegant way to solve problem.

Also, last but not least, you can try to enforce this kind of concept even if you are not a programmer.

DRY

The DRY concept is pretty clear, it stands for Don’t Repeat Yourself.
It means that you should avoid duplication at all cost.
I think we don’t need to develop a lot on this point because it seems obvious but it would help fight :

• Errors : If you have the same logic at multiple places, then an error or a change of that logic needs to be duplicated as well. You can imagine how easy can things go wrong here.
• Reliability : Seeing logic implemented multiple times in your code make it looks very suspicious for other developer. Also, if any change happen to only one of the place. No one will notice probably…

YAGNI

This acronym stands for You Ain’t Gonna Need It. This is the one I am struggling personally the most with. It is a very beginner-friendly trap.
You start developing your code and you start to think of all the potential use-cases and try to cover them all.

This goes often sideways because you don’t have proper requirement for the use-cases you are trying to cover. At the end of the day, it may come that the requirements are totally different and you need to re-do the whole code.

So trying to prepare your code for flexibility is a good thing but overdoing it can really bring more nightmares in the future.

KIS

Keep It Simple : This is a direct relation with the previous statement.
You should always try to keep your code as minimalist as possible.
As stated in the book; the simpler the design, the more maintainable it will be.

A function that you create should be answering to one use-case and one use-case only.
The data that you retrieved should be used in one way, and one way only.
If you need to append information to that data in that case, and remove information for another case.

It should probably be handle by different functions. It can be that your function is doing different things, but it should have one global purpose.

EAFP/LBYL

Those 2 acronyms stand for :

• Easier to Ask Forgiveness than Permission
• Look Before You Leap

The 2 ideas are not really compatible, it is either one or the other approach but in both case you are prepared and you are fully committed to the approach.

The EAFP approach is to try to run the script and catch the exceptions that may occur (Forgiveness).

The LBYL is to check that the condition are satisfied before running your code. (look before)

You could do both technically, but then your program won’t crash at all and it is not always a good thing. You may want it to crash if the user is using the program / function in an incorrect way. Enforcing the correct usage is definitely a good approach.
It goes a bit back to other concepts that I won’t explain here but I encourage you to research.

• Defensive Programming
• Design by Contract

I hope these different acronyms resonate to you as much as it resonated for me. I feel that trying to select the approach that are being presented is a good way to start on custom code.

As stated in the article mentioned at the beginning (…Long Live Custom Code). It should not be the first option, but when you do it, do it right. 😉