# Clean code

## Clean code

- [Introduction](https://gpcoder.gitbook.io/clean-code/overview/intro.md): Clean Code - A Handbook of Agile Software Craftsmanship by Robert C. Martin (Uncle Bob)
- [Why is clean code so important?](https://gpcoder.gitbook.io/clean-code/overview/why-is-clean-code-so-important.md)
- [What Is Clean Code?](https://gpcoder.gitbook.io/clean-code/overview/what-is-clean-code.md)
- [How to write clean code?](https://gpcoder.gitbook.io/clean-code/overview/how-to-write-clean-code.md)
- [Conventions](https://gpcoder.gitbook.io/clean-code/overview/conventions.md)
- [Meaningful Names](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/meaningful-names.md): Names are everywhere in software. We name our variables, our functions, our arguments, classes,  packages, source files, directories, ... What follows are some simple rules for creating good names.
- [Functions](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/functions.md): Functions should be small and do one thing.
- [Classes](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/classes.md)
- [Comments](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/comments.md): Always try to explain yourself in code.
- [Error Handling](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/error-handling.md)
- [Exception handling best practices](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/error-handling/exception-handling-best-practices.md): These Java Exception handling best practices provide software developers guidance when they develop new applications.
- [Unit Tests](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/unit-tests.md)
- [Formatting](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/formatting.md): Code formatting is important.
- [Objects and Data Structures](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/objects-and-data-structures.md)
- [Simple Design Rules](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/simple-design-rules.md)
- [Concurrency](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/concurrency.md): Objects are abstractions of processing. Threads are abstractions of schedule.
- [Code Smells](https://gpcoder.gitbook.io/clean-code/the-key-principles-of-clean-code/code-smells.md)
- [Write Short Units of Code](https://gpcoder.gitbook.io/clean-code/building-maintainable-software/write-short-units-of-code.md): Limit the length of code units to 15 lines of code. Do this by not writing units that are longer than 15 lines of code in the first place, or by splitting long units into multiple smaller units.
- [Write Simple Units of Code](https://gpcoder.gitbook.io/clean-code/building-maintainable-software/write-simple-units-of-code.md): Limit the number of branch points per unit to 4. Do this by splitting complex units into simpler ones and avoiding complex units altogether.
- [Write Code Once](https://gpcoder.gitbook.io/clean-code/building-maintainable-software/write-code-once.md): Do not copy code. Do this by writing reusable, generic code and/or calling existing methods instead.
- [Keep Unit Interfaces Small](https://gpcoder.gitbook.io/clean-code/building-maintainable-software/keep-unit-interfaces-small.md): Limit the number of parameters per unit to at most 4. Do this by extracting parameters into objects.
- [Write Clean Code](https://gpcoder.gitbook.io/clean-code/building-maintainable-software/write-clean-code.md): Writing clean code is what you must do in order to call yourself a professional.
- [Automate Tests](https://gpcoder.gitbook.io/clean-code/building-maintainable-software/automate-tests.md): Automate tests for your codebase. Do this by writing automated tests using a test framework. This improves maintainability because automated testing makes development predictable and less risky.
- [SOLID Principle](https://gpcoder.gitbook.io/clean-code/bonus/solid-principle.md)
- [SRP - Single Responsibility Principle](https://gpcoder.gitbook.io/clean-code/bonus/solid-principle/srp-single-responsibility-principle.md): A class should have one and only one reason to change, meaning that a class should have only one job.
- [OCP - Open-Closed Principle](https://gpcoder.gitbook.io/clean-code/bonus/solid-principle/ocp-open-closed-principle.md): Objects or entities should be open for extension, but closed for modification.
- [LSP - Liskov Substitution Principle](https://gpcoder.gitbook.io/clean-code/bonus/solid-principle/lsp-liskov-substitution-principle.md): Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
- [ISP - Interface Segregation Principle](https://gpcoder.gitbook.io/clean-code/bonus/solid-principle/isp-interface-segregation-principle.md): Many client-specific interfaces are better than one general-purpose interface.
- [DIP - Dependency Inversion Principle](https://gpcoder.gitbook.io/clean-code/bonus/solid-principle/dip-dependency-inversion-principle.md): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
- [LoD Principle](https://gpcoder.gitbook.io/clean-code/bonus/lod-principle.md)
- [YAGNI Principle](https://gpcoder.gitbook.io/clean-code/bonus/yagni-principle.md): You aren't gonna need it
- [DRY Principle](https://gpcoder.gitbook.io/clean-code/bonus/dry-principle.md): Don't Repeat Yourself Principle
- [Fail Fast principle](https://gpcoder.gitbook.io/clean-code/bonus/fail-fast-principle.md): When a problem occurs, it fails immediately and visibly.
- [Hollywood Principle](https://gpcoder.gitbook.io/clean-code/bonus/hollywood-principle.md): Don't Call Us, We'll Call You.
- [Library vs Framework](https://gpcoder.gitbook.io/clean-code/bonus/library-vs-framework.md)
- [Coupling and Cohesion](https://gpcoder.gitbook.io/clean-code/bonus/coupling-and-cohesion.md): The primary OO goals are loose coupling and high cohesion. The key to creating maintainable code is adhering to loose coupling, high cohesion.
- [AOP - Aspect-Oriented Programming](https://gpcoder.gitbook.io/clean-code/bonus/aop-aspect-oriented-programming.md)
- [Building an AOP framework](https://gpcoder.gitbook.io/clean-code/bonus/aop-aspect-oriented-programming/building-an-aop-framework.md)
- [OOP Design Pattern](https://gpcoder.gitbook.io/clean-code/bonus/oop-design-pattern.md)
- [Technical Dept](https://gpcoder.gitbook.io/clean-code/bonus/technical-dept.md): Technical debt management requires a balance between quality and speed. Technical debt needs to be understood, used and managed from a long-term perspective.
- [How to learn software Design and Architecture - Roadmap](https://gpcoder.gitbook.io/clean-code/bonus/how-to-learn-software-design-and-architecture-roadmap.md): The Full-stack Software Design & Architecture Map
- [Microservcies](https://gpcoder.gitbook.io/clean-code/bonus/microservcies.md)
- [Defining the scope of a microservice](https://gpcoder.gitbook.io/clean-code/bonus/microservcies/defining-the-scope-of-a-microservice.md)
- [Step-by-Step: How to Identify Over-Scoped Microservices](https://gpcoder.gitbook.io/clean-code/bonus/microservcies/step-by-step-how-to-identify-over-scoped-microservices.md)
- [Benefits of Grouping or Consolidating Microservices](https://gpcoder.gitbook.io/clean-code/bonus/microservcies/benefits-of-grouping-or-consolidating-microservices.md)
- [A practical step-by-step plan to consolidate microservice](https://gpcoder.gitbook.io/clean-code/bonus/microservcies/a-practical-step-by-step-plan-to-consolidate-microservice.md)