Scribd
Upload
56 views21 pages

Clean Code

This document discusses principles and best practices for writing clean code, including: 1. Code should have meaningful names, avoid ambiguous names, and use searchable variable names. 2. Magic numbers should be avoided and replaced with named constants. Methods should have a single responsibility, use verbs in names, and avoid flag arguments. 3. Comments should be avoided when possible by writing clear, intention-revealing code. Formatting and structure are also important for readability. 4. Error handling should use exceptions rather than return codes, and tests should follow the FIRST principles with one assert per test. Classes and modules should have a single responsibility.

Uploaded by

Rajesh Jangra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
56 views21 pages

Clean Code

This document discusses principles and best practices for writing clean code, including: 1. Code should have meaningful names, avoid ambiguous names, and use searchable variable names. 2. Magic numbers should be avoided and replaced with named constants. Methods should have a single responsibility, use verbs in names, and avoid flag arguments. 3. Comments should be avoided when possible by writing clear, intention-revealing code. Formatting and structure are also important for readability. 4. Error handling should use exceptions rather than return codes, and tests should follow the FIRST principles with one assert per test. Classes and modules should have a single responsibility.

Uploaded by

Rajesh Jangra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

CLEAN CODE

RAJESH KUMAR

1
WHAT IS CLEAN CODE

 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 is complete,
 Clean code does one thing well.
Bjarne Stroustrup

2
MEANINGFUL NAMES

 int i;
 What is i?
 int elapsedTime;
 Now we know it is an integer indicating elapsed time.
 But what time? Seconds, years what?
 int elapsedTimeInDays
 Better?
 int elapsedTimeInDaysSinceRestart
3
MEANINGFUL NAMES

 controllerForEfficientHandlingOfStrings
 controllerForEfficientStorageOfStrings
 Frightfully similar
 int a = l;
   if ( O == 0 ){
     a = O;
}
 Not very clear?
4
MEANINGFUL NAMES

 Names with similar meaning


 accountData vs account
 customerInfo vs customer
 Variable names should be pronounceable
 dtValFmtddmmyy
 dateValueFormattedAsddmmyy
 Use searchable names
 If you must search a variable named “a”

5
NO MAGIC NUMBERS

public List<int[]> getList(List<int[]> inputList) {


List<int[]> tempList = new ArrayList<>();
for (int[] x : inputList)
if (x[0] == 4) tempList.add(x);
return tempList;
}

6
NO MAGIC NUMBERS CONTD

public List<int[]> getFlaggedCells(List<int[]> gameBoard) {


List<int[]> flaggedCells = new ArrayList<>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}

7
METHODS

 Method name must be verb


 One name per concept
 Fetch, retrieve, get
 Do not add too much context
 E.g. Prefixing everything with application name
 Must always return value
 Should not have side effects
8
METHODS CONTD

 Keep methods small


 And make sure it does one thing
 Niladic, monadic and dyadic
 Triadic is so evil, try enclosing in a class if really required
 So are flag arguments, It means method does more than one thing

9
FUNCTIONS CONTD

 Command query separation


 Method should do something or answer something but not both
 Prefer exceptions to returning error codes
 Violate the command query separation
 The error codes class is dependency magnet

10
WORDS OF WISDOM

 Every function, and every block within a function, should have one entry
and one exit.
 Means that there should only be one return statement in a function,
 no break or continue statements in a loop,
 and never, ever, any goto statements.
 Dijkstra

11
COMMENTS

 What would you prefer?


// Check if employee is eligible for full benefits
if (employee.flag && employee.age > 65)
 Or
if (employee.isEligibleForFullBenefits())

12
COMMENTS

 Do not comment bad code, rewrite it, refactor it


 Kernighan
 If your code can not reveal its intention, then the comments shall neither.
 The comments are seldom maintained
 Comments clutter the code
 TODO comments

13
FORMATTING

 Is as important as the code itself


 Should be standardized for a project
 The old Hollerith limit of 80 is a bit old and most screens allow width greater than
that

14
ABSTRACTION

 Do not blindly create getters and setters


 Understand when to use
 Procedural
 Object oriented
 DTOs do nothing more than to duplicate code

15
ERROR HANDLING

 Use informative error messages


 Do not catch and re-throw
 Use exceptions rather than error codes
 Write try-catch-finally in separate function?
 Checked vs Unchecked exceptions?
 Violates open closed principle

16
TESTS

 F.I.R.S.T. principle
 Tests must be uniquely named
 Given-When-Then
 One assert per test
 Making a private function protected to test
 Generally, not required if the functions are small

17
CLASSES

 Single Responsibility Principle


 Too many classes
 Look for cohesion
 Dependency Inversion Principle
 Enums vs constants
 Do not inherit constants

18
SYSTEM

 Object creation should be separated from business logic


 Dependency Injection, Factories
 Cross cutting concerns
 Business logic should be separate from framework related code

19
SYSTEM

 Always delete commented code


 And dead code i.e unreachable code
 Building and deploying a system should be one step
 Should be able to run all tests on local
 Do not override safeties
 Maintain separation between layers

20
QUESTIONS?

21

You might also like