> For the complete documentation index, see [llms.txt](https://gpcoder.gitbook.io/clean-code/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gpcoder.gitbook.io/clean-code/overview/how-to-write-clean-code.md).

# How to write clean code?

Writing clean code is a lot like painting a picture. Most of us know when a picture is painted well or badly. But being able to recognize good art from bad does not mean that we know how to paint. So too being able to recognize clean code from dirty code does not mean that we know how to write clean code!

A programmer who writes clean code is an artist who can take a blank screen through a series of transformations until it is an elegantly coded system.

There are two parts to learning clean code: **knowledge** and **work**:

* You must have knowledge of the principles, patterns, practices, and experience that a craftsman knows. 
* You also have to grind those skills through hard work and practice.

Clean code consists of:

* Your developer mindset (empathy, craftsmanship, growth mindset, design thinking)
* Your coding conventions (naming things, refactoring, testing, etc)
* Your skills & knowledge (of patterns, principles, and how to avoid code smells and anti-patterns)

## Follow clean code principles

The most important principles to keep our code clean:

* [**SOLID**](/clean-code/bonus/solid-principle.md)**\***: **S**ingle Responsibility Principle (SRP), **O**pen-Closed Principle (OCP), **L**iskov substitution principle (LSP), **I**nterface Segregation Principle (ISP), and **D**ependency Inversion Principle (DIP).
  * Design principles, this is a topic in itself but mastering the **SRP** will already help us in a tremendous way.
* KISS (**K**eep **I**t **S**imple **S**tupid):
  * Simplicity should be a key goal in design, and unnecessary complexity should be avoided. 
  * The question to ask when you're writing code is "can this be written in a simpler way?” 
* [DRY](/clean-code/bonus/dry-principle.md) (**D**on't **R**epeat **Y**ourself):
  * Each piece of knowledge must have a unique, unambiguous, authoritative representation in a system. 
  * When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. 
* [YAGNI](/clean-code/bonus/yagni-principle.md) (**Y**ou **A**ren't **G**onna **N**eed **I**t):
  * A developer should not add functionality unless deemed necessary. 
  * Always implement things when you actually need them, never when you just foresee that you need them.
* Boy-scout rule: Always leave the code better than you found it. 
* Don't reinvent the wheel: There are already tons of libraries that can help solve our problems so we don't have to do it again. 
* [Design Patterns](/clean-code/bonus/oop-design-pattern.md): There are tons of design patterns out there, and some people already resolved our problem. 
* Coding Standards/Conventions: So we don't end up having different codes with different coding styles among our team.

## Create the habits of clean coding

* Follow standard conventions. Keep them clear and concise. 
* Be consistent. Use the same names in similar functions (Get vs Fetch, Set vs Update, Add vs Append). 
* [If you copy-paste code multiple times, consider better ways to make your code more efficient](/clean-code/building-maintainable-software/write-code-once.md). 
* If you feel that a piece of code is too complex or not the best way to do it, then stop! Give yourself a few moments to rethink the process and see if you can come up with a better way. 
* Review with colleagues. Compare their code with yours, and be open to suggestions. 
* Self-review code/ Peer review code. 
* Always find the root cause. Always look for the root cause of a problem. 
* Refer to the key principles of the Clean Code book.
* [When writing a new unit, never let it grow beyond 15 lines of code](/clean-code/building-maintainable-software/write-short-units-of-code.md). 
* [Limit the number of branch points per unit to 4](/clean-code/building-maintainable-software/write-simple-units-of-code.md).
* [Limit the number of parameters per unit to at most 4](/clean-code/building-maintainable-software/keep-unit-interfaces-small.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gpcoder.gitbook.io/clean-code/overview/how-to-write-clean-code.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.