# Codification

Why is it so important?

# 6 key aspects

Linting; helps with consistency, which is a key element for Automation.
2. Testing; scientific methods of ensuring the reproducibility of a given process.
3. Collaboration; is only possible if everybody speaks the same “language”
4. Abstract modeling; Visually representation like graphs or graphics become possible.
5. Separate concerns; Build individual modules that solve only one problem.
6. Documentation; if it's written down, it is by definition a document.

This was a Eureka moment for me.
Sounds Stupid?
Maybe, but for me now, a lot of concepts I was using made so much more sense.

# 1. Linting

Lint, or a linter, is a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs.
Wikipedia

It's like Grammarly for your code.

# 2. Testing

Science relies on Reproducibility of results.
In order to believe a phenomenon, it must be possible to reproduce it as an outcome of similar circumstances.

In simple terms, it means if you claim that something is true.
You must describe the system, what your input and output parameters were… If anyone with the knowledge provided and skill can reproduce the outcome, it must be true.
No miracles! For coding, this means if you write a test, provide your code and a description of the dependencies used. Everybody must be able to reproduce the outcome.

No more, *works on my Machine.

There is a debate going on in the community because some study founds that published papers are too often not Reproducible but repeatable.

# Repeatability

A result is repeatable if doing the same experiment over and over again produces the same answer. The mathematical language that describes repeatability is statistics.
The p-value describes how likely it is to get the same result (within a margin) when an experiment is repeated.
If a P value is 0.01, this means if you repeat the experiment 100 times, only one of the results would lie outside a confidence interval.

# Reproducibility

A result is reproducible if other labs can follow the experimental protocol and get the same results.

# 3. Linguistic relativity

States that the way people think of the world is influenced directly by the language that the people use to talk about it.
Or more radically, people could only perceive aspects of the world for which their language has words. Source

According to anthropological linguist Daniel Everett, language can be considered a cultural tool to relate a community’s values and ideals and is shaped and molded by these residents over time.

Sounds familiar?
If your coding language of Choice has no library for something, you can't code it straight away.
Yes you can build your own or work around it, but this is similar to words that exist in one language but not in the other, you then try to describe it in a whole sentence. But you will never come 100% to it.

An easier way to explain this is with color perception. The number of terms we have for the colors we see varies from one language to another. For instance, English speakers name different shades of blue as dark blue and light blue. Russian speakers have two distinct categories for blue: it’s either siniy (dark blue) or goluboy (light blue). We do the same thing for another color: dark red and light red — the latter of which we call pink! With this, people who speak two or more languages are expected to focus differently regarding colors because different languages distinguish color in various ways.

# Etymology

Also, sometimes concepts mean different things despite the same word.

Take the Indo-European word "blak" meant Shining fire** at that time.
From there the French developed the word "blanc" for white.
Probably because if you look into a fire it's white.
While the English developed, the word "black" for black.
Probably because if something burned it leaves ash back which is black.
Source

# 4. Imperative vs. Declarative

Imperative programming is a paradigm describing HOW the program should do something by explicitly specifying each instruction (or statement) step by step, which mutates the program's state.

Declarative programming is a paradigm describing WHAT the program does, without explicitly specifying its control flow.

At the end of the day, everything compiles instructions for the CPU.
So in a way, declarative programming is a layer of abstraction on top of imperative programming.

# Imperative

Its best analogy is a Cake Recipe, first do that, secondly do that, finally do that.
Step by Step.

Programming Languages like C, PowerShell, Rust, Python, JavaScript… are Imperative.

# Declarative

Desired State configuration, is a way in which you only specify a list of attributes.
I want one Chocolate Cake for 12 People, with candles and red marzipan roses on top.

Good examples are PowerShell-DSC, Ansible, Terraform, Dockerfile.

Declarative code is usually refereed to as a configuration file like a Dockerfile, a ansible-playbook in a .yaml file.
This is a bit misleading, because these files get 'Interpreted' like python***.py*** files, and produce a output based on that Input.

# Idempotency

Declarative can be but does not necessarily have to be Idempotent.
Think of it like this:
if you go to the same bakery twice for the Chocolate Cake, they will only make you one. Because you wanted ONE, not TWO.

The Output does not change no matter how often you run your function.

# 5. DRY

Do not repeat yourself.

Every piece of knowledge must have a single, unambiguous authoritative representation within a system.

Source

If you noticed that you copy some code and have similar code in the same file, it would be best to put it in a function.
Now you can call this function as often as you will.
The same goes for constants, if they are really constant, then it's fine to set them in the file as a Global Variable.
i.e. PI = 3.14...
If they could in theory change, then it's not a constant and should be defined in a config file.

# Downside

DRY increases coupling and coupling can be bad.

# Coupling

a device that joins two things together:

Source
If you have a function that is shared across multiple files/projects, then all depend on the agreed function of that function.
So if you change the Function it changes for every project.
So you have to be careful this can be good but also bad if something breaks it breaks for everyone.
Also, in Security, if you have a vulnerability in one part of your code, all projects are affected.
Coupling is a way of abstraction, but you have to be careful that Abstraction brings in Value.

Visual Explanation - YouTube

# Interfaces

Description of the "shape" of an Object.
Who to interface or interact with it?
Description of the parameters, input variables and so on.

# Cohesion

If there is cohesion within a society, organization, or group, the different members fit together well and form a united whole.

# 6. Documentation

the process of recording something in a Document

By definition, if you coded it, it is documented.
No need to do it twice.

That said, this is more true for Declarative Languages.
And for Imperative Languages, it can be true if Variable and Function naming is done properly.

But coding practices also help to automate the Documentation Process.
This Blog post does a great job of pointing out how to automate Documentation.

# Conclusion

Now that we have everything in Code how do we keep it neat and tidy?
How do we keep track of changes and who did what and when to the code over time?
Enter Versioning.