The document discusses object calisthenics and best practices for writing clean code. It outlines 9 simple rules for writing code in a better way, including having only one level of indentation per method, not using else keywords, wrapping primitive types that have behavior, using first class collections, having one dot per line, not abbreviating, keeping entities small, limiting instance variables, and not using getters and setters. The goal is to challenge developers to rethink how they write code to improve maintainability, readability, and testability.

1. CLEAN CODE,
OBJECT CALISTHENICS
& BEST PRACTICES
- by#MM17NYC @mhgontijo

2. Matheus Gontijo
Y-E-E-A-A-H-H, we have a #Brazilian in the house, folks!
So ware Engineer at
Over 6 years of experience with Magento platform
Speaker and attendee to conferences all over the world
on twitter - ping me there ;- D
Crimson Agility
MCD & MCD+
@mhgontijo

3. What KILLS So ware Developers
so badly?

5. uhmm... there are
PLENTY some guys still writing code
in our community like that...

6. Poorly written code equals...
💩💩💩
countless hours of energy being drained
HUGE amount of time wasted === MONEY wasted
...it's unpleseant... it discourages the entire team to work
with that mess

7. How can we improve our code?
EXERCISING!

8. Object Calisthenics!
btw has anybody ever heard about it?

9. Cal • is • then • ics
/ˌkaləsˈTHeniks/
Greek word that means
gymnastic exercises.

10. The concept was created by Jeff Bay in his
book The ThoughtWorks Anthology
A collection of exercises to focus on
maintainability, readability, testability, and
comprehensibility of your code.

11. PHP Community?
Rafael Dohms -
Keynode Speaker, Evangelist, and founder of PHPSP &
PHPAmsterdam... which are awesome!
Guilherme Blanco -
Core Committer at Doctrine, Symfony and Zend Framework
@rdohms
@guilhermeblanco

12. THAT SHOULDN'T BE EXTREMELY...
COMPLEX!!!

13. 9 simple rules
to write code...
WAY BETTER ✌

14. 9 simple rules advices
to write code...
WAY BETTER ✌

15. BUT don't follow them blindly....
It's NOT binary: RIGHT or WRONG
There is not one-size-fits-all
No Silver Bullet
Don't take what I'm saying as absolute truth :- P
the main goal is to challenge yourself...
to make you RE-think the way you code...

16. 30 minutes only
just going through quickly ; )
the examples are very simple just for the sake of easy
understanding

17. #01 ADVICE
Only One Level Of Indentation Per
Method

20. Example:
Let's say you are creating a
process to update description

26. Benefits:
Easy to understand!
Single Responsibility Principle ("S" in S.O.L.I.D.)
Encourages Re-use

27. #02 ADVICE
Don't Use The ELSE Keyword

28. Example:
Let's create a class in order to
subscribe emails to a newsletter
group called VIP.

29. Rules:
It has to be a valid email.
The email can not be registered again, if it already is.
The email has to have a customer assigned the same email.
The customer assigned to that email needs to be assigned
to VIP Group also.

34. Benefits:
Decreases Cyclomatic Complexity
Prevents Code Duplication
Legibility (Single Path)

41. #03 ADVICE
Wrap All Primitives Types And Strings,
If It Has Behavior

42. When?
When your type needs validations, business rules or
behaviors
Email
Zipcode
Phone Number
IP Address
IBAN, ISBN
URL
List of status as Pending, Denied, Approved
...

43. Example:
Let's say you are creating a class to
send emails.

58. Benefits:
Type Hinting
Encapsulation of business rules
Prevents Code Duplication
Implements Value Objects of DDD

59. #04 ADVICE
First Class Collections

62. Benefits:
Single Responsibility Principle ("S" in S.O.L.I.D.)
Implements SPL Interfaces
Class for Filtering, Mapping, Ordering & other

63. #05 ADVICE
One Dot Per Line

64. #05 ADVICE
One Dot "->" Per Line

70. Law of Demeter

71. *** EXCEPT ***
for Fluent Interfaces/Method Chaining
since it was designed to work that way

73. Benefits:
Law of Demeter
Legibility

74. #06 ADVICE
Don't Abbreviate

80. Benefits:
Legibility
Maintainability

81. #07 ADVICE
Keep All Entities Small

83. Long files are hard to read... so...
No methods with over 20 lines
No namespaces over 15 files
Class with 200 lines maximum
Very challenging!

84. Benefits:
Legibility
Maintainability

85. #08 ADVICE
No Classes With More Than Two Five
Instance Variables

87. Benefits:
Higher Cohesion
Lower Coupling
Shorter Dependency list
Maintainability

88. #09 ADVICE
No Getters and Setters!
just my favorite ❤ ❤ ❤

89. Example:
Let's create a approval process for
comments.

90. It's very important to the system to
track the following:
Previous Status
New Status
User that made the change
Date

91. John is creating the a new approval record...
Status: PENDING

92. Mary is creating the a new approval record...
Status: PENDING ---> FIX_TYPO

93. David is creating the a new approval record...
Status: FIX_TYPO ---> APPROVED

96. h4ck3r is creating the a new approval record...
Status: APPROVED ---> APPROVED

97. h4ck3r is creating the a new approval record...
Status: DENIED ---> DENIED

98. Solution?
ENCAPSULATION!
We have to HIDE business logic!
BTW it's not something new... it's just encapsulation... basic concept of OOP

99. Now nobody will no longer be able
to mess up the process ;- D

101. That's it!
✌ ✌ ✌ ✌

102. Recap
1. Only One Level Of Indentation Per Method
2. Don't Use The ELSE Keyword
3. Wrap All Primitives Types And Strings, If It Has Behavior
4. First Class Collections
5. One Dot "->" Per Line
6. Don't Abbreviate
7. Keep All Entities Small
8. No Classes With More Than Two Five Instance Variables
9. No Getters and Setters!

103. and the most important thing is...

104. You should give
Object Calisthenics a try!
Take a month and see how good that is!

105. Questions?
@mhgontijo