Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clean Code

Clean Code

What, Why, and How Clean Code.

Avatar for Tien Nguyen Xuan

Tien Nguyen Xuan

July 07, 2020
Tweet

More Decks by Tien Nguyen Xuan

Other Decks in Programming

Transcript

  1. What and Why Clean Code ? ▶ Easy to understand.

    ▶ Easy to maintenance. ▶ Contains no duplication. ▶ Simple is the best.
  2. Meaningful name ▶ Value,Id Names - Need to make sense,

    choose descriptive and unambiguous names, no duplication. ▶ Class Names - Should have noun or noun phrase names like Transaction, Account, and TransactionParser. - Should not be a verb. ▶ Function Names. - Should have verb or verb phrase name like sendData() , deleteAccount()… - Accessors ,mutators ,and predicates should be named for their value and prefixed with get, set, and is according to the javabean standard.
  3. Comment Tips ▶ Comments Do Not Make Up for Bad

    Code. ▶ Don’t be redundant. ▶ Use as explanation of intent. ▶ Use as clarification of code. ▶ Use as warning of consequences. ▶ Do not Commented-Out Code. ▶ TODO comment for something you have not done yet.
  4. SOLID Principles ▶ Single Responsibility Principle. (SRP) ▶ Open-Closed Principle.

    (OCP) ▶ Liskov Substitutions Principle. (LSP) ▶ Interface Segregation Principle. (ISP) ▶ Dependency Inversion Principle. (DIP)
  5. SRP ▶ Every class should have a single responsibility ▶

    Split big classes into smaller ones, and avoid God Classes.. What should be done ? Always think of the logic and the business rules which are only applicable for that class.
  6. OCP ▶ Software entities should be open for extension but

    closed for modification. What should be done ? Write your codes in a way so that, if someone wants to add a new functionality to the class in future, he or she won’t have to touch your existing code.
  7. LSP ▶ Child classes should never break the parent class’

    type definitions.. What should be done ? If you have two classes, class A and class B, where B is a subclass of A, all the methods which are mentioned in class A should have implementation in class B.
  8. ISP ▶ No client should be forced to depend on

    methods it does not use. It means : We should split large and fat interfaces into several small and lighter one are based on specific intent. What should be done ? Segregate the interface for each class
  9. DIP ▶ 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. What should be done ? We should not extend concrete classes, we should always depend on abstractions like abstract classes or interfaces.