Clean code is a buzzword and a boogieman in the software industry. There're books called "Clean code" and there're social-network-based fights on what could be called "clean code" and what couldn't.
Why it is difficult to create a "clean code formula"? I have been thinking about it lately and I think I was able to come up with something interesting.
Programming code we write is not only instructions for a computer, but also a form of communication. Just think about it - we try to write something which:
👉 can be understood by a computer
👉 can be reasonably easy read (and written!) by programmer
👉 is reasonably easy to change
👉 as well as communicate the "grand plan" of a software system architecture
And I haven't yet mentioned that it should be:
👉 reasonably efficient (with every task having different efficiency requirements)
👉 and not consume unnecessary memory.
Clearly, it is not an easy task. It also isn't something100% objective and/or measurable.
Different people have different readability "requirements". I am assuming this is mostly defined by what kind of code they were exposed to, but there might be something else going on.
A similar challenge is with "grand plan"/"architecture" communication - depending on what kind of applications one worked with as well as personal paradigm preferences there may be quite big differences in understanding of what could be a good architecture direction.
The worst thing is that in many cases the objective differences are, in fact, marginal. Similarly "code smells" are just heuristics and not definitive tests.
So, while it is great if you care about writing clean code, keep yourself open-minded and never assume that you know "the formula"
Interested? Then check out the next post on clean code - "The most important code smells"
Top comments (0)