Clean Code: Looking to write better code? 

Clean Code: Looking to write better code? 

Every professional developer strives to implement good code. In this article, our Technical Manager, Vanesa Schimpf, shares some insights on how Clean Code can help you produce quality software.

Have you ever come across a bad code? Surely yes, and you probably felt impeded or delayed because of that bad code. Did it surprise you when you realized that you wrote that bad code? Don’t worry, it has happened to all of us. 

As professional developers, sometimes, we are under pressure, running to finish what we promised in the time we promised. Maybe our boss will think we’re wasting our time if we delay our delivery by improving a solution that’s actually already working. We think that we will have time to improve it later, but that later never comes. 

clean code

What we sometimes don’t realize is that this bad code impacts us in many ways. It decreases productivity by taking so long to understand it, it introduces errors by not being maintainable, each new change is more difficult and riskier by not being scalable, and even small requirements that should be easy and limited, end up being big changes that impact other places in the system. As the system grows with bad code, it becomes too complicated to continue working on it, and we begin to realize that we need to refactor it. Many refactors tend to be large, and it is sometimes tough to define the scope. We usually start by changing a small piece, but then we discover that it won’t be enough if we don’t improve the next part, so we end up with giant refactors that introduce a lot of bugs and generate a lot of re-work in all areas. At this point, there is not much more that we can do, and we end up with two possible situations: continue with infinite refactors or start with a new system in parallel with all that it implies (more resources, more time, more money). 

We could avoid all those problems if we write good code! Yes, the responsibility is ours as programmers, and we have the power in our hands to define the result of what we create. It is easy to fall into bad code; however, as the authors, we can lead the experience that future readers will have when going through our code. Since we want to be good professionals, we must strive to produce quality software. 

What is Clean Code? 

The Clean Code term was used by Robert C. Martin in his book Clean Code: A Handbook of Agile Software Craftsmanship to describe a set of software design principles that help produce intuitive and maintainable code. Robert, or Uncle Bob, proposes a series of guides and good practices that every good programmer should follow in their nomenclatures and conventions.  

In his book, you can find different interpretations of this term, where I can extract some interesting words: elegant code, easy to read and understand, efficient and performant, with minimal dependencies, with error handling, direct and focused on a single responsibility, with unit tests, and nothing obvious that can be improved. 

Some of these guidelines and good practices are summarized below. 

Main practices for writing good code 

When creating new variables, it is very important to take the time to choose good names — those that make sense and leave no room for speculation or ambiguity. The name must be precise and self-explanatory of the intention and ultimate objective. It is also sensible to make them easily pronounceable so that they are easily grasped in our minds and can be referenced when discussing the code with someone else. Avoid variables with only one letter or that include the data type, very long or very similar names, or even too generic names that complicate the search and references. 

These recommendations also apply to classes and methods, where we can add that they should be small and have a single responsibility. The classes must follow the concept of encapsulation and have their respective unit tests. Methods should have as few parameters as possible and avoid flag parameters as they would mean different methods. Look for 0 duplicity and 0 comments, greater reuse and expressive code, and functions without side effects. 

Pay close attention to Code Smells! 

The so-called Code Smells refer to suspicious code of being refactored. In other words, they are like flags that call our attention and invite us to look at it more closely, because perhaps it is necessary to improve it. 

Among all the Code Smells, I can highlight: 

  • Function with many arguments 
  • Dead code, no one calls it 
  • Duplicated code 
  • Feature envy: too much usage of variables and functions from another class 
  • Magic numbers: Sometimes we see fixed numbers in the code that we don’t know where they came from, and they are not put into constants. 
  • Huge classes or functions that clearly don’t handle a single responsibility 
  • Negative conditionals, which are harder to understand 
  • Confusing or unintelligible names 
  • Reusing variables for different purposes 
  • Parameter overriding 
  • Many levels of nesting 
  • Lack of unit tests 

If in these cases we carry out transformations that maintain the behavior, but at the same time change the internal structure so that it is easier to understand and modify, to correct possible bugs and simplify the logic, we will end up with a good code. 

The last lines 

As professional developers, it is our responsibility to implement good code. It is the mark we leave that shows us how we are as professionals, if we are committed to our work and seek excellence. 

A sentence at the beginning of the book struck me: “Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.” 

Undoubtedly, fixed delivery times, changes in requirements, resources with little experience (or a lack of them), different priorities in the team, unclear roles, lack of methodology, and coordination problems are everyday issues that threaten the code quality. Still, no one else is responsible for having good code other than ourselves, the developers. 

Finally, I would like to close with the well-known analogy from the Boy Scout rule: Leave the code cleaner than you found it. Let’s not adhere to the typical excuse, it was already like this. Let’s make the code that we modify as if it were our own code. Let’s plan possible small refactors and the inclusion of the respective unit tests as part of our tasks. 

For more information and details, I invite you to read Uncle Bob’s Clean Code book and thus, become better developers to leave good code wherever you go. 

White Paper

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need. 

WHY TO HAVE IT?

DevOps is a new way of collaboration that makes processes change for the better. The idea of this paper is to understand why you need DevOps and to learn how you can get started. You will walk through the key ideas that bring development and operations together to produce higher-quality software.

White Paper
×

WHY TO HAVE IT?

With an eye on business demands on having clean code, the idea of Technical Debt has emerged. The problem is a software product can only handle so much Technical Debt before it begins to crumble under the weight of its own inefficiency. Learn here how to tackle Technical Debt properly.

White Paper
×

WHY TO HAVE IT?

Companies who are successfully incorporating continuous innovation into their business practices have changed the way their enterprise software is deployed. Trends in application development and deployment support organization-wide transformation but which type of architecture is right for you?

White Paper
×

READY TO TAKE A LOOK?

Many organizations around the world are transferring their IT and software development operations to third parties. For most of them, thinking about outsourcing is an issue of efficiency and focus. Don’t miss these interesting facts that show you why this might be the perfect choice for your business.

White Paper
×

WHY TO HAVE IT?

In the search for the perfect solution, it is not uncommon to find that off-the-shelf products don’t offer solutions fitting your needs and business model. This is where a software development partner comes in. If you are looking to understand what software consultants companies can do for you, keep reading.

White Paper
×

Event-Driven Architecture (EDA) An old concept for a modern context

The concept of Event-Driven Architecture (EDA) may not be new in the software development industry; however, it is becoming stronger once again, thanks to its flexibility and adaptability by using information in real time. At the same time, EDA offers companies the opportunity to process events and flows of events that result in immediate analysis.

White Paper
×

A Beginner’s Guide to Scrum in Agile Projects

Scrum has proven to be very useful in any field and industry, regardless of its complexity. This quick and easy guide aims to show the main insights this methodology has, how it works, and other important aspects to consider if you want to start in the Agile world and improve your company’s results.

White Paper
×