Même le code source mal écrit s’exécute! Du code source qui n’est pas propre peut grandement affecter l’efficacité d’une organisation de développement logiciel. Chaque année, d’innombrables heures sont perdues par les équipes de développement à cause d’un code source mal écrit.

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