0% found this document useful (0 votes)
6 views

cleanCode

The document discusses the importance of clean code, highlighting issues such as bloated classes, code duplication, and the liabilities associated with excessive code. It outlines the concept of technical debt, its causes, and the 'Rule of Three' for refactoring code effectively. Additionally, it identifies various code smells, including bloaters, change preventers, dispensables, and couplers, which hinder code maintainability and clarity.

Uploaded by

usaeranother
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

cleanCode

The document discusses the importance of clean code, highlighting issues such as bloated classes, code duplication, and the liabilities associated with excessive code. It outlines the concept of technical debt, its causes, and the 'Rule of Three' for refactoring code effectively. Additionally, it identifies various code smells, including bloaters, change preventers, dispensables, and couplers, which hinder code maintainability and clarity.

Uploaded by

usaeranother
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

Clean code

- bloated classes and methods makes code sloppy and difficult to grasp.
- code duplication - each time you have to make a change in a duplicate code, you
have to remember to make the change in every instance.
- code is liability - less code means, less things to manage.

Technical debt- metaphor used to regard unlean code


Causes
- Business presssure
- lack of understanding of the consequence of techincal debt
- lack of documentation - new people cannot join easilyy
- lack of tests - often without immediate feedback, work around and patches get
encouraged.
- failing to combat strict coherence - usin monolith rather than individual
modules. Team development is made more difficult, as it is harder to isolate
individual members.
- Delayed refactoring- as the project progesses and requirement changes some old
code gets obsolete, but new code is written alongside old code, and the debt
accumulates.
- Lack of compliance monitoring - happens when everyone works on the project and
writes code as they see fit (i.e the same wat they wrote the last project).

Rule of Three
When you’re doing something for the first time, just get it done.

When you’re doing something similar for the second time, cringe at having to repeat
but do the same thing anyway.

When you’re doing something for the third time, start refactoring.

While adding a new feature or fixing a bug start by refactfring

How to refactor
- The main objective is code should become cleaner.
- New functionality shouldn't be created during refactorying - seperate refactorin
with direct development.
- All existing test sholuld pass.

Bloaters
When the function, class has become so big it is very hard to work with.

Long Methods - it suggests a method should not be more than 10 lines. It is


easier to write code than to read it. And usually codes are more often added in a
function than removed.
* Treatment
-Extract method - If even a single line should be explained. Put it inside another
method.
-Replace Temp with Query -
-Introduce Parameter Object - Replace repeating group of parameters with an object.
-
Object Orientation Abusers

Change Preventers
This smell means if you have to change a code in one place, you have to make many
changes in other places too.

Dispensables
Those are codes that are pointless or unneeded.
Couplers
All the smells in this group contribute to excessive coupling between classes or
show what happens if coupling is replaced by excessive delegation.

You might also like