KeffHey there π I'm back with another short little post.
There are many articles about this thing we call "clean code". But I feel they lack some important concepts.
Some people seem to think that "clean code" will just appear by following some guidelines or using design patterns, etc... This is not true per se, if you use guidelines, patterns, and so on without knowing why or when to use them they can lead to dirtier code (for lack of a better word). Though they can help if applied correctly.
Note that "clean code" is not a science and is highly opinionated. One person might say that doing X thing is better than doing Y, while the other might say the contrary. And both would be right, what is "clean code" for me does not necessarily mean it's clean for you.
My take
For me, "clean code" is a process that is the result of your effort, discipline, and experience over time. Code is never "clean" or in its best form the first time it's written, not even the second iteration. It becomes "cleaner" over time, step by step.
clean_code = (effort + discipline + experience) / time
I also think the term "clean code" is misleading and makes it feel like there is only one way of doing it, and once it's clean it cannot be improved more.
I'd prefer to talk about "clean(er) code" instead of "clean code". Or maybe even dispose of the term completely, because what the fuck does "clean" mean? My house can be clean for me, but be hella dirty to you.
There are also many examples that just show how a simple function or small piece of code can be "cleaned". And yes, these examples are valid for small code snippets, but not so much for bigger-scale apps. As you have to deal with pressure, timeframes, and code-style rules that might prevent you from doing some of the "clean code" practices. (Hopefully the team enforces good practices and makes code more consistent, though it's not always the case)
Β This is what cleaner code is for me
- Knowledge of the language
- Understanding the guidelines
- Discipline and effort
- Time
- Experience
Note the last point "experience". This is a point that is mostly ignored when talking about this topic, but it's an important one.
I think experience plays a big role in making "cleaner" or more readable code. If you just started coding I would not expect your code to be pretty or readable. Once you have coded for years, day after day, you start to value the importance of writing good quality code that is readable and maintainable.
I wrote a post about refactoring, which kinda goes hand to hand with this one, here it is in case you want to check it out:
Hope you enjoyed this short little post. Let me know what your thoughts are on my view, do you agree? Or do you have some other view?
That's it for this one, now let's go write some ugly code shall we? π₯΄
