CLEAN CODEPar : Abdelhakim Bachar

Plan

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

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

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

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

Data Structures

• Data Abstraction• The Law of Demeter• Data Transfer Objects

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

Class

• Class Organization– Encapsulation

• Classes Should Be Small– The Single Responsibility Principle– Cohesion

• Organizing for Change– Isolating from Change

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

Refactoring

• First, Make It Work• Then Make It Right

Smells and Heuristics

• General • Environment• Comments• Functions• Java• Names• Tests

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

Smells and Heuristics : Environment

• Build Requires More Than One Step• Tests Require More Than One Step

Smells and Heuristics : Comments

• Inappropriate Information• Obsolete Comment• Redundant Comment• Poorly Written Comment• Commented-Out Code

Smells and Heuristics : Functions

• Too Many Arguments• Output Arguments• Flag Arguments• Dead Function

Smells and Heuristics : Java

• Avoid Long Import Lists by Using Wildcards

• Don’t Inherit Constants• Constants versus Enums

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

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

Merci à vous