10 Main Takeaways from Clean Code

EBS Integrator
Feb 22, 2021,

package main 
import "fmt"
var WhatIsThe = AnswerToLife()
  func AnswerToLife() string {
				return "Clean Code" 
  func init()	{
		WhatIsThe = "Clean Code"
    func main() { 
		if WhatIsThe =="Clean Code" {
					    fmt.Println("Hello World!")
//the end?


Arguably the most recognizable 2-word sentence in a programmer’s repertoire.

Be it Java, C++, C#, Python, or a dozen other languages; they all have the same first lesson. If you’re still not sure which one hits closer to home, we’ve touched on it before. But today we want to reiterate one of the most important lessons in programming – “Write self-explanatory code” or “Clean code”

Sounds great, incredibly hard to achieve though! But as they say “An ounce of prevention is worth a pound of cure”. Writing slower but cleaner is paramount, especially when chasing performance and optimization deadlines.

My name is Irina Batiri and I work as a “Junior Python Developer” at EBS Integrator. In 2019 I began studying python in my free-time and a year later, I landed this job. For the past two years I have been diligently improving my craft and today I’d like to tell you all about a book. This one became a favourite of mine, in an instant – not because of the hype, but rather due to its essence.

Clean Code” by Bob Martin (Uncle Bob) is probably the most recommended work and author in our field. Even though the examples presented in the book relate to Java, the same principles apply for most languages.

Following are my personal key conclusions after reading this great book. Chief among them being: Read the book, it is worth it!


1. Refactoring of a working code is the second part of the job, not an optional activity.

The code that works is only half the battle. The job can only be considered done after the code has been refactored in such a way that it can be easily understood by another programmer.

2. Code quality = code longevity.

Clean, predictable and self-explanatory code is maintainable. Any other programmer will be able to read and change it if required. Coworkers will use existing methods put in place instead of rewriting or generating new ones. They will not have to spend time figuring out what the existing code is about and for that, will be forever grateful.

clean code

3. Meaningful names.

  • Function or class name should have a name telling what this piece of code is doing without having to deploy a comment.
  • The function should have no side effects – it should do what its name implies.
  • Function name length is proportional to its scope. It is ok to have a counter named “i” in a small loop, but it is not ok to have a variable named “data” in a class.

Bad: time = 4 # elapsed time in days

Good: elapsed_time_in_days

4. Single Responsibility Principle.

Functions & classes should be responsible for 1 thing only. If a function is long (longer than 5 lines) – it does more than 1 thing.

“<…> way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation.”

There is a great resource helpful for refactoring of Python code (just pick “Python” in code snippets). You can check out various options for refactoring a long method, for instance.

clean code

5. Level of abstraction.

If a function calls upon other functions, executes some own logic, and only then returns a list of results you’re in trouble. Avoid such structures at all cost. This abstraction levels mix will only create confusion.

Discerning levels of abstraction:

    • In order to save information from a website to our database we need to:
      • Parse the website
    • In order to parse the website we need to <…>
      • Process the information – prepare it for saving & save it to the database
    • In order to process the information we need to <…>
      • Save it to the Database
    • In order to save the information to the database we need to <…>

6. Ordering of the functions.

Reserve the top of the file to functions that call other ones, followed by those “called functions”. This way, the person reading it can skim through the file and get the core premise of the code. Think of the main function as of a chapter and of those subsequent ones, as of a recap.

clean code

7. Number of function arguments.

  • The best function has no arguments. A function with 1 or 2 arguments is not perfect, but acceptable.
  • A function with more than 3 arguments is a failure.
  • Boolean argument is ugly – “loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another if the flag is false!”

There are several ways to fix the issue with a large number of function arguments.

8. DRY principle.

Do not repeat yourself. Repeated code is an ideal environment for bugs.

9. Comments are evil.

  • If you feel you need to leave a comment – most likely the function/ variable/ class was badly named. Consider renaming it.
  • Code that was commented out should not get into commit.

10. Dead (unused) code should be removed.

This is code pollution that draws away readers’ attention and makes them doubt the overall code quality.


As a Junior Python Developer, I found the book to be a treasure trove of useful information that helped me and my colleagues optimize our workflow. There’s a reason why programmers have this running joke that trying to figure out a code you wrote half a year ago. With no regard to quality, figuring out that code is like trying to understand a foreign language.

clean code

xkcd: code quality

I know what you’re thinking – “Clean code, the premise sounds great but I have a deadline to meet”; and it’s easy to make the mistake to rush your work, and “code faster”. But what happens is that overall, the project takes longer.  With cluttered code, routines like fixing unexpected issues and adding a new team member are “Mission Impossible”. More often than not, it all leads to a feeling of “looking for a needle in a haystack.” There’s a popular quote that comes to mind.

“We like to think we spend our time power typing but we actually spend most of our time staring into the abyss.” – Jason Douglas Crockford

These were my top 10 main takeaways after only the first reading of the book. And I must say that listening to Uncle Bob’s lectures on the same topic helped me understand his approach so much more. If you do not have time to read the book – consider listening to his talks. Uncle Bob is simply inspiring and his talks help understand and motivate yourself to adhere to the book rules.

I am sure that I will keep coming back to this book throughout the years. If not only, to get a better understanding of the rules (which are currently deeper than my knowledge), but also to maintain the habit of writing clean code. Even for the grizzled veterans of development out there, it’s certainly one to add to the top of your book-bucket list!


This is by far not the only thing to consider when building your development strategy. Be it for a new app, startup or pet project, “Clean Code” is important – especially in crowded companies. You know the saying: Two’s a company, three’s a crowd? Well, make sure to set those fundamentals straight. Whether it’s about the approach you should use or what framework to consider, you build “for the many” – so deploy a universal language within your source.

Make sure to visit our blog regularly to get your fresh injection of grey matter juice in the tech startup world.

And now let me bid you farewell! But before you go tell us in the comment section if you agree with our opinion or maybe you think that there’s a better author with similar views! Or simply leave us a thumbs up! Stay safe out there, fellow tech nerds!