This document provides an outline for a course on clean code. It covers principles of clean code like high signal-to-noise ratio, self-documenting code, and the right tool for the job. It also discusses techniques for writing clean code, such as naming conventions, writing high-quality functions and classes, using conditionals effectively, and using comments judiciously. The document is presented over several pages with headings and subheadings to structure the content.

1. CleanCode
Writing code for humans
PAGE 1

2. Course
Outline
Introduction
Principles
Naming
Conditionals
Functions
Classes
Comment
Stay Clean
PAGE 2

3. Author
PAGE 3
CTO @ DEHA Technologies
Startup Entrepreneur
COO @ Closet.vn
Bien Hoang

4. Introduction
PAGE 4
Coding is for humans
Why is clean code matter?
Clean code is the Foundation
Resources
We will cover

5. Coding is for humans
“Programing is the art of telling another human what one wants the computer to do.”
Donald Knuth
Author of “The art of computer programing”
“Any fool can write code that a computer can understand. Good programmers write
code that humans can understand.”
Martin Fowler
Chief Scientist @ Through Work
PAGE 5

6. Why is clean code matters?
Reading is harder than writing
Technical debt is depressing
You’re lazy
No time to sloppy
Don’t be a verb
PAGE 6

7. Clean code is the Foundation
Clean Code
SOLID Code
Refactoring
DDD TDD
Automated Testing
Design Pattern
PAGE 7

8. Comparisons
Dirty
// Dirty code snippet
Clean
// Clean code snippet
PAGE 8

9. Resources
Code Complete Clean Code
PAGE 9
The Pragmatic
Programmer

10. Principles
PAGE 10
Three clean code principles
We will cover

11. Three
principles of
clean code
1. Right tool for the job
2. High signal to noise ratio
3. Self-documenting
PAGE 11

12. The right tool for the right job
 Creative using wrong tool is not something brag you
 Watch for boundaries
PAGE 12

13. The right tool for the right job
 Stay Native – Advantages
PAGE 13
Cached
Avoid string
parsing
Can minify
& obfuscate
Code
colored
Syntax
checked
Separation
of concerns
Reusable

14. The right tool for the right job
 Avoid using one language to write another language/format via strings.
 Leverage libraries
 One language per file.
PAGE 14

15. High signal to noise ratio
Signal
 Terse (Short)
 Expressive
 Do one thing.
Noise
 High cyclomatic complexity
 Excessive indentation
 Zombie code
 Unnecessary comments
 Poorly named structures
 Huge class
 Long methods
 Repetition
 No whitespace
 Overly verbose
PAGE 15

16. High signal to noise ratio
1. Our brain is the compiler
The “Rule of 7” effects:
 Number of parameters per method
 Number of methods in a class
 Number of variables currently in scope
2. The mess builds quietly
PAGE 16

17. Don’t Repeat Yourself – DRY Principle
Duplication Issues
1. Decreases signal to noise ratio.
2. Increases the number of lines of code.
3. Create a maintenance problem.
PAGE 17

18. Self-document code
“Understand the original programmer’s intent is the most difficult problem.”
Fjelstad & Hamlen 1979
 Clear intent
 Layers of abstractions
 Format for readability
 Favor code over comments.
PAGE 18

19. Naming
PAGE 19
Why is naming critical?
Names to avoid
Avoiding side-effects
Selecting good variable names
We will cover

20. Why naming matters?
Understanding the programmer’s intent is the biggest problem.
PAGE 20

21. Naming class
WebsiteBO
Utility
Common
MyFunctions
JimmysUtils
*Manager/*Processor/*Info
PAGE 21
User
Account
QueryBuilder
ProductRepository

22. Class Naming Guidelines
Noun Be specific
Single
Responsibility
Avoid generic
suffixes
PAGE 22

23. The Method Name Says It All
Go
Complete
Get
Process
DoIt
Start
On_Init, Page_Load, etc
PAGE 23
GetRegisteredUsers
IsValidSubmission
ImportDocument
SendEmail
Write a good method name, the reader doesn’t
need to read the body of the method to know
what it does.

24. Rubber Ducking
 Verbalizing aids creativity
 Stuck? Verbalize!
 Ask: Am I describing one thing?
 Read more: https://seal.deha.vn/?p=2402
PAGE 24

25. Avoid side effects
 CheckPassword shoudn’t log user out.
 ValidateSubmission shouldn’t save.
 GetUser shouldn’t create their session.
 ChangeCreditCard shouldn’t send emails.
 Make sure method names are comprehensive and tell the whole truth
PAGE 25

26. Naming Warning Signs
 And
 If
 Or
If you use one of them to concatenate method name, you should need more than one method.
PAGE 26

27. Avoid Abbreviation
 It’s not the 80s
 No standard
 We talk about code.
RegUsr
RegistUser
RegisUser
RegisterUser
PAGE 27

28. Naming Variables: Booleans
open
start
status
login
If (login) {
}
PAGE 28
isOpen
done
isActive
loggedIn
If (loggedIn) {
}

29. Naming Variables: Be Symmetrical
On/disabled
Quick/slow
Lock/open
Slow/max
PAGE 29
On/off
Fast/slow
Lock/unlock
Min/max

30. Conditionals
PAGE 30
Clear intent
Bite-size logic
Use the right tool
Sometimes code isn’t the answer
We will cover

31. Compare Booleans Implicitly
If (loggedIn == true)
PAGE 31
If (loggedIn)

32. Assign Booleans Implicitly
bool goingToTravel
If (cashInBank > 6000)
{
goingToTravel = true;
} else {
goingToTravel = false;
}
PAGE 32
bool goingToTravel = cashInBank > 6000;
 Fewer lines
 One declaration
 No repetition
 Reads like speech

33. Be Positive
If (!isNotLoggedIn)
PAGE 33
If (loggedIn)

34. Ternary is Beautiful
Int registrationFee;
If (isSpeaker)
{
registrationFree = 0;
} else {
registrationFee = 50;
}
PAGE 34
Int registrationFee = isSpeaker ? 0 : 50;
Honors DRY: Don’t repeat your self.
YAGNI: You ain’t gonna need it (add complexity
when needed)

35. Be Strongly Typed, Not “Stringly” Typed
If (employeeType == “manager”)
PAGE 35
If (imployee.type == EmployeeType.Manager)
 No typos
 IntelliSense
 Document states
 Searchable

36. Magic Numbers
If (age > 21)
{
}
If (status == 2)
{
}
PAGE 36
const int legalDrinkingAge = 21
If (age > legalDrinkingAge)
{
}
If (status == Status.active)
{
}

37. Complex Conditionals
PAGE 37

38. Complex Conditionals
PAGE 38
Favor expressive code over comments

39. Favor Polymorphism Over Switch
PAGE 39

40. Favor Polymorphism Over Switch
PAGE 40

41. Be Declarative
PAGE 41

42. Table Driven Methods
PAGE 42

43. Table Driven Methods
 Great for dynamic logic
 Avoids hard coding
 Write less code
 Avoids complex data structures
 Make changes without a code deployment
PAGE 43

44. Methods
PAGE 44
High signal functions
When to create a function
Techniques to maintain simplicity
Approaches to minimize variable
lifetime
Signs a function is to long
Exceptions and error handling
We will cover

45. When to create functions/methods ?
PAGE 45
Avoid
Duplication
Indentation
Unclear
intent
> 1 task

46. Why to create functions/methods?
PAGE 46
DRY
Less is
More
Code is a
liability
Indentation

47. Indentation Solution - Extract Method
PAGE 47

48. Indentation Solution - Fail Fast
PAGE 48

49. Indentation Solution - Fail Fast
PAGE 49

50. Indentation Solution - Return Early
PAGE 50

51. Indentation Solution - Return Early
PAGE 51

52. Indentation Solution - Return Early
PAGE 52

53. Unclear Intent Solution – Convey Intent
PAGE 53

54. Do One Thing
PAGE 54
Aids the
reader
Promotes
reuse
Eases naming
and testing
Avoid side-
affects

55. Mayfly Variables
Mayfly variable recipe
1. Initialize variables just-in-time
2. Do one thing.
PAGE 55

56. How Many Parameters?
PAGE 56

57. How Many Parameters?
PAGE 57

58. Sign It’s Too Long
PAGE 58
A function should be
1. Rarely be over 20 lines
2. Rarely over 3 parameters
Whitespace &
Comments
Scrolling
required
Naming
issues
Multiple
Conditionals
Hard to digest
(Rule of 7)

59. Handling Exceptions
PAGE 59
Can’t handle the exception?
Fail fast. Fail loud
Unrecoverable
Null reference
File not found
Access denied
Recoverable
Retry connection
Try different file
Wait and try again
Ignorable
Logging click

60. Try/Catch/Log = Fail Slow
PAGE 60

61. Try/Catch/Log = Fail Slow
PAGE 61

62. Summary
PAGE 62

63. Classes
PAGE 63
Class are look like headings
When to create a class
Measuring quality
Cohesion
Name
Size
Primitive obsession
Proximity principle
Outline rule
We will cover

64. Classes Are Like Book Headings
PAGE 64

65. When to create classes?
• Abstract or real-world
New concept
• Method should relate
Low Cohesion
• Small, targeted => reuse
Promote Reuse
• Solve once, hide away
Reduce complexity
• Identify a group of data
Clarify parameters
PAGE 65

66. Class Responsibilities Should Be Strongly Related
PAGE 66
 Enhances readability
 Increases likelihood of reuse
 Avoids attracting the lazy
 Watch for
- Standalone methods.
- Fields used by only one method
- Classes that change often.

67. Low vs High Cohesion
PAGE 67

68. Broad Names Lead to Poor Cohesion
PAGE 68

69. Signs a Class is to Small
PAGE 69

70. Primitive Obsession
PAGE 70

71. Proximity Principle
PAGE 71

72. The Outline Rule
PAGE 72

73. The Outline Rule
PAGE 73

74. Summary
PAGE 74

75. Comments
PAGE 75
A necessity and a crutch
Comments to avoid
Useful comments
We will cover

76. A Necessity and a Crutch
PAGE 76

77. Redundant Comments
PAGE 77

78. Intent Comments
PAGE 78

79. Apology Comments
PAGE 79

80. Warning Comments
PAGE 80

81. Zombie Code
Common Causes
 Risk Aversion
 Hoarding mentality
PAGE 81

82. Divider Comments
PAGE 82

83. Brace Tracker Comments
PAGE 83

84. Bloated Header
PAGE 84

85. Defect Log
PAGE 85

86. Clean Comments
TODO Comments
Documentation
Summary Comments
PAGE 86

87. Summary
PAGE 87

88. Staying Clean
PAGE 88
When to refactor
Techniques for staying clean
We will cover

89. When to Refactor to Clean Code
PAGE 89

90. Code Review and Pairing
Code Review Work in Pairs
PAGE 90

91. Accept No Broken Window
PAGE 91

92. The Boy Scout Rule
PAGE 92