The document presents principles of clean code as articulated by Abdelhakim Bachar, emphasizing meaningful names, function organization, data structures, error handling, and unit tests. Key strategies include using intention-revealing names, ensuring functions do one thing, proper error handling with exceptions, and maintaining cohesive classes. It also highlights common code smells and heuristics to avoid for cleaner, more maintainable code.

1. CLEAN CODE
Par : Abdelhakim Bachar

2. Plan
• Introduction
• Meaningful Names
• Functions
• Data Structures
• Error Handling
• Class
• Unit Tests
• Refactoring
• Smells and Heuristics

3. Introduction
What Is Clean Code? There are
probably as many definitions as there
are programmers.
I like my code to be elegant and efficient. The logic should be
straightforward to make it hard for bugs to hide, the
dependencies minimal to ease maintenance, error handling
complete according to an articulated strategy, and
performance close to optimal so as not to tempt people to
make the code messy with unprincipled optimizations. Clean
code does one thing well.
Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

4. Meaningful Names
• Use Intention-Revealing Names
• Avoid Disinformation
• Use Pronounceable Names
• Avoid Encodings
• Class Names
• Method Names
• Pick One Word per Concept
• Don’t Pun
• Use Solution Domain Names

5. Functions
• Small
• Do One Thing
• One Level of Abstraction per Function
• Use Descriptive Names
• Function Arguments
• Command Query Separation
• Prefer Exceptions to Returning Error
Codes

6. Data Structures
• Data Abstraction
• The Law of Demeter
• Data Transfer Objects

7. Error Handling
• Use Exceptions Rather Than Return Codes
• Write Your Try-Catch-Finally Statement First
• Provide Context with Exceptions
• Define Exception Classes in Terms of a
Caller’s Needs
• Define the Normal Flow
• Don’t Return Null
• Don’t Pass Null

8. Class
• Class Organization
– Encapsulation
• Classes Should Be Small
– The Single Responsibility Principle
– Cohesion
• Organizing for Change
– Isolating from Change

9. Unit Tests
• The Three Laws of TDD
• Keeping Tests Clean
– Tests Enable the -ilities
• Clean Tests
– Domain-Specific Testing Language1
– A Dual Standard
• One Assert per Test
– Single Concept per Test
• F.I.R.S.T

10. Refactoring
• First, Make It Work
• Then Make It Right

11. Smells and Heuristics
• General
• Environment
• Comments
• Functions
• Java
• Names
• Tests

12. Smells and Heuristics : General
• Multiple Languages in One Source File
• Incorrect Behavior at the Boundaries
• Duplication
• Base Classes Depending on Their Derivatives
• Too Much Information
• Dead Code
• Vertical Separation
• Function Names Should Say What They Do
• Follow Standard Conventions
• Replace Magic Numbers with Named Constants
• Be Precise
• Avoid Negative Conditionals
• Functions Should Do One Thing
• One Level of Abstraction
• Keep Configurable Data at High Levels
• Avoid Transitive Navigation

13. Smells and Heuristics : Environment
• Build Requires More Than One Step
• Tests Require More Than One Step

14. Smells and Heuristics : Comments
• Inappropriate Information
• Obsolete Comment
• Redundant Comment
• Poorly Written Comment
• Commented-Out Code

15. Smells and Heuristics : Functions
• Too Many Arguments
• Output Arguments
• Flag Arguments
• Dead Function

16. Smells and Heuristics : Java
• Avoid Long Import Lists by Using
Wildcards
• Don’t Inherit Constants
• Constants versus Enums

17. Smells and Heuristics : Names
• Choose Descriptive Names
• Choose Names at the Appropriate
Level of Abstraction
• Use Standard Nomenclature Where
Possible
• Avoid Encodings
• Names Should Describe Side-Effects

18. Smells and Heuristics : Tests
• Insufficient Tests
• Use a Coverage Tool!
• Don’t Skip Trivial Tests
• An Ignored Test Is a Question about an
Ambiguity
• Test Boundary Conditions
• Exhaustively Test Near Bugs
• Tests Should Be Fast

19. Merci à vous