Skip to Content


Post: 10 common broken rules of clean code

10 common broken rules of clean code


From time to time I am asked to do code review of an application. I like doing this, because it is always learning experience. I can see how others program, what problems they have and how they solve them. Except that I can see code written in various conditions and by people with different skills and experience. I prepared a list of 10 popular “clean code” broken rules which I often encounter during this code reviews and I would like to share this list with you.

Note: If you don’t know what clean code means, I recommend to read Robert C. Martin Clean Code book.

1. Bad and inconsistent naming

var od = new OrderDetails(); // Too short, no meaningful

var order = new OrderDetails(); // not full

var ordrDetals = new OrderDetails(); // misspelling

var OrderDetails = new OrderDetails(); // incorrect, should be camelCase

var orderDetails = new OrderDetails(); // correct

var ordersDetailsList = new List<OrderDetails>(); // incorrect, variable type included

var orderDetails = new List<OrderDetails>(); // correct

var detailsOfOrder = new List<OrderDetails>(); // correct, alternative form

var detailsOfOrders = new List<OrderDetails>(); // correct if we have details of different orders

Naming is very often neglected (especially by less experienced developers) but it shouldn’t. Good naming sometimes is difficult but it is needed for a good level of code redability and maintainability.

2. Too much comments

// Get order details
var orderDetails = orderDetailsRepository.GetById(orderId);

// Set invoice number.

// Calculate total price.
decimal totalPrice = 0;
foreach (var item in orderDetails.Items)
    totalPrice += item.Price;

// some unused code...
// some unused code..
// some unused code..

// Set total price

Comments from line 1, 4, 7, 18 are not needed, becasue code speaks for itself. Comment block from lines 14-16 are not needed too, this code should be removed - our source control will remember everything :).

Comments are needed only in two cases:

  • commenting public API.
  • when programmer uses some kind of hack and there is no other way to explain this.

In other cases comments are unnecessary and should be avoided. You should use refactor technique called Extract Method instead.

3. Duplication

The same code occurring more than once. If it is not intended, it should be refactored by moving that code to separate class and/or method. See Don’t Repeat Yourself (DRY) principle.

4. Sloppy formatting

public void SomeMethod()
    List<int> integers = new  List<int>( ); // unnecessary spaces

                                                    // too big gap between statements

    for (var index = 0; index < 10; index++) { // curly bracket in invalid place

  if (integers.Count == 10)
                            // bad indenations

Similar to bad naming. It doesn’t affect execution of our code but it affects readability. Some people will say that is minor issue but I will say it is not. What do you think about book which is not formatted good? What do you think about author and editor of this book? In programming we should have the same rules because we are professionals, aren’t we?

5. Too big classes/methods

Classes and methods should be as small as possible. They should have “only one reason to change” as Single Responsibility Principle says. Common code smells are:

  • too much lines of codes
  • too many dependencies (constructors/methods parameters)
  • code in class concerning different entities, use cases

6. Bad exceptions handling

int number = 0;
    var divideResult = 5 / number;
catch (Exception e) // exception too general
    throw e; // stack trace information is lost

We should always catch the most specific exception (DivideByZeroException for example above). Moreover, we should be careful when we try rethrow given exception, because we can lost whole stack trace information. Below corrected code:

int number = 0;
    var divideResult = 5 / number;
catch (DivideByZeroException e)

7. No encapsulation

This is most frequently broken rule of clean code and object oriented design paradigm. I see this almost in every codebase. Every class is public with public properties and public methods. This is not object oriented programming. Our duty is to create fully encapsulated objects and hide theirs internals. This is topic for another post why to do this but for know I beg you - stop revealing your classes internals only because your IDE add public keyword by default.

8. Too many conditional statements

Sometimes, when our bussiness logic is complicated, I see a lot nested if/else statements. This is difficult to read and understand.

Often we can get rid part of this statements applying some design pattern and principle (see The Open/Closed Principle and Strategy Pattern for example). If we can’t, we should decompose these conditionals.

9. Unused code

Unused code is created in 2 cases. First case is when code was changed (due to refactoring or requirements change) and some part of that code is not valid. Second case is when programmer wanted to add some additional functionality which is not required at the time of writing but he thinks it may be needed later.

In both cases unused code should not exist. It decreases redadabilty of code, design, adds unnecessary complexity to them - it should be avoided. There is even programming principle for second case - YAGNI.

10. Magic strings and numbers

Programming is enough difficult even without magic. Code with meaningless strings and numbers like Option == 1, order.Type = 'A' is difficult to read, maintain and refactor. Instead of this we should use enums and consts and enjoy good readability and compile-time checks.


I tried to list all most common issues which I often encounter. I think it is important to remember at least two things when we write the code. Firstly, code is more often read than written. Secondly, working code which even fulfills business requirements is not sufficient if it is written badly. Remembering this and knowing rules of writing good quality code will lead us to software craftsmanship faster.

Image credits: storyset on Freepik.


Related posts See all blog posts

GRASP - General Responsibility Assignment Software Patterns Explained
8 April 2019
GRASP – General Responsibility Assignment Software Patterns (or Principles). There are far fewer materials on the Internet about this topic, so I decided to bring it closer because I think the principles described in it are as important as the SOLID principles.
Read More