Often it is said that coding is a way to communicate with machines and that way is optimised for them.
However, this is untrue and I will detail to you why.
At the beginning of the programming history communication with computers was done by the intermediate of cards which were on one side pierced with a certain number of holes and on the other side, there were words from a programming language that was close to Pascal language. The holes on the side of these cards were the direct binary from the Pascal written on the other side.
For machines, this way to proceed was one of the best and if we were optimizing for machines it would have not been necessary to go to some more complex.
However we did, so if it is not for machines that we did this for who?
To this question, the answer is simple and is mostly YOU.
Another concept often misunderstood is that code is about reading and not writing.
Even if a programmer always finishes by writing, he always needs first to read code around to get the context where he gonna add some code or find the place to change the code.
Often the ratio is that a developer spends 75% of his time reading and only 25% of his time writing.
This ratio is not true on every project but as much as a project grows this ratio augment in favour of reading.
So most of the time when you’re on a project you are reading yourself and you need to still understand what you wrote at that moment.
On a project where you are not the only developer writing something easily understandable is even more vital because your colleagues never wrote the code so they need to decrypt the logic from the code you left.
This is where architecture and clean code takes effectiveness. Both reduce chances to do errors while reading and understanding. Moreover, it also allows the programmer to read faster and reduce interactions in the team that are not high value.
For developers, these practices provide a better experience while programming and for business better effectiveness of programmers on the project on a long period.
Now that we know why it is important to write understandable code it is time to explain the difference between these two concepts.
The main difference between architecture and clean code is the level where they apply.
Clean code will be at a base level and about the organisation of functions in a class, names of variables, functions and class.
Where architecture will be about splitting and organizing classes, libraries and packages.
To make this distinction less vague, let’s see some examples of practices and to which topic they refer.
The first practice I want to share with you is a method to distinguish between a variable and a function without having to understand the syntax of a programming language.
A variable is always storing something and can’t be used to execute a certain action. Due to this, you should always name a variable with one or multiple nums.
A function is containing a certain number of actions inside itself and by calling the function you gonna execute them. Due to that, you should always name a function with a verb.
This trick can look simple and it is but the benefit are enormous while reading the code because now we don’t have to rely on syntax or be obliged to check if a certain notion is a variable or a function while reading it.
This practice occurs directly on the code and how we write it, that’s why it is low level. Due to that, this trick deals with clean code.
A practice that can be linked with architecture can be the usage of SOLID principles.
SOLID are principles that enable code from a project to remain easily understandable and maintainable.
These principles are at a number of five and every single letter from the SOLID word stand for one:
- Single responsibility: A class should have only one reason to change
- Open Close: A class should always be open for extension but never for modification
- Liskov substitution: Your code should be still functional when we use a child from your class.
- Interface segregation: Always divide your interfaces as much as possible
- Dependencies inversion: Always rely on abstract classes or interface nor concrete classes
These fives principles can look a bit abstract the first time you see them but hopefully, a set of predefined solutions respecting these rules exist and are called design patterns.
Many sources explain and detail these patterns but the one that explains to me the best is Refactoring Guru. If you are interested in this topic I invite you to check this link: https://refactoring.guru/design-patterns/catalog
As you can see these trick has to deal with organisation and structure from your code which is a higher level that is why it is linked to clean architecture.
However, even if we saw in the last part that these topics are different often authors that write about these topics abord both topics.
If you are interested in going deeper on making your code cleaner, Uncle Bob, a famous writer in the programming world has two books on these concepts, one about each topic:
- Clean code: https://www.amazon.com/dp/B08X8ZXT15
- Clean architecture: https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
I hope this first post about programming on Medium learnt you something and I am open to any comments on improving my article.
Leave a Reply