Andre Toropchin 4ndrey

## clean_code.md

      
              1 file
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                4ndrey
                / clean_code.md
            
            
              Created
              December 9, 2018 19:51
                — forked from wojteklu/clean_code.md
            
              
                Summary of 'Clean code' by Robert C. Martin
              
          
    Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules


Follow standard conventions.
Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
Boy scout rule. Leave the campground cleaner than you found it.
Always find root cause. Always look for the root cause of a problem.

Design rules


## gist:e819a876db9e3a43a012220ca79d8e03
The next three principles deal with the coupling between components:

    the Acyclic Dependancies Principles. As soon as you begin using component, you should allow no cycles in the dependancy graph. It's always possible to break a cycle with Dependancy Inversion Principles. Important note : the component structure cannot be designed from the top down, it evolves as the system grows. Component dependancy diagrams are a map to the build-ability and maintainability of the application.
    the Stable Dependencies Principle. Some components are designed to be volatile. We expect them to change. Any of these should not depend on a component that is difficult to change. We should depend in the direction of stability. Again employing the DIP can help us to apply this principle breaking dependency on a stable component.
    the Stable Abstractions Principle. A component should be as abstract as it is stable. The software should encapsulates the high level policies (business rules) of the system into stable component
	The next three principles deal with the coupling between components:

	the Acyclic Dependancies Principles. As soon as you begin using component, you should allow no cycles in the dependancy graph. It's always possible to break a cycle with Dependancy Inversion Principles. Important note : the component structure cannot be designed from the top down, it evolves as the system grows. Component dependancy diagrams are a map to the build-ability and maintainability of the application.
	the Stable Dependencies Principle. Some components are designed to be volatile. We expect them to change. Any of these should not depend on a component that is difficult to change. We should depend in the direction of stability. Again employing the DIP can help us to apply this principle breaking dependency on a stable component.
	the Stable Abstractions Principle. A component should be as abstract as it is stable. The software should encapsulates the high level policies (business rules) of the system into stable component