Clean Code Highlights for Real Projects

Clean code highlights for variables, functions, and classes naming and functions definition that can be used in real in real life.

Transcript

1. Clean Code Highlights for Real Projects Florin Trifu Senior Developer Emag
3. Content • What is Clean Code? • The Productivity Trap • Code Rot • Names, the invisible enemy • Functions
4. Disclaimer The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. (https://www.ietf.org/rfc/rfc2119.txt)
5. WHAT IS CLEAN CODE?
6. Is this clean code?
7. Is this clean code?
8. Mathematical intervals • (a, b) – open • [a, b] – closed • (a, b] – open left • [a, b) - open right
9. Is this better?
10. What is clean code? Bjarne Stroustrup: “I like my code to be elegant and efficient. Clean code does one thing.”
11. What is Clean Code? Michael Feathers (author of Working Effectively with Legacy Code) “Clean Code always looks like it was written by someone who cares.”
12. THE PRODUCTIVITY TRAP
13. First symptom Rushing to get more things done!
14. Zeno’s paradox Achilles and the tortoise
15. Code Rot • Rigidity • Fragility • Inseparability • Opacity
16. Rigidity A rigid system is a system in which a single change or enhancement forces you to make dozens of other changes throughout the body of the system
17. Fragility Fragile systems are systems that break in many places when you touch them in just one
18. Inseparability An inseparable system is a system composed of modules that can’t be separated and reused for other purposes
19. Opacity Opaque code is code that do not communicate the author’s intent, is hard to read, hard to understand, hard to change
20. NAMES
21. Reveal your intent
22. Ottinger’s Rules for Variables and Class Naming Every time you choose a name, it should reveal the intent of the thing you’re trying to name; if a comment is needed, then the name does not sufficiently reveal the intent.
23. Reveal your intent Names that describe implementation details do not reveal intent; they talk more about the code as it is and why it was written that way , than they talk about the problem being solved.
24. Reveal your intent Whenever you need to read the code in order to understand the name, the name has pretty much failed to communicate. Names are not for your convenience, but rather the primary tool for communicating your intent.
25. Naming rules • Avoid disinformation • Pronounceable names • Avoid encodings
26. Naming rules • Classes and variables are nouns, methods are verbs • Avoid noise words like Manager, Processor, Data or Info; they are just synonyms for “I don’t know how to call this” • Boolean should be written as predicates • If a method returns a Boolean, should be written as predicate
27. The Scope Length Rule • For variables: THE LONGER THE SCOPE OF THE VARIABLE, THE LONGER THE NAME • For classes and functions: THE LONGER THE SCOPE, THE SHORTER THE CLASS OR FUNCTION NAME SHOULD BE. THE SHORTER THE SCOPE, THE LONGER THE CLASS OR FUNCTION NAME SHOULD BE.
28. FUNCTIONS
29. Function size
30. The first rule of functions They should be small!
31. The first rule of functions Blaise Pascal: “I’m sorry this letter was so long, but I didn’t have time to make it smaller”
32. The first rule of functions How long should a function be? 30 lines? 20 lines? Surprise, surprise… 5 Lines!
33. One thing! A function should do one thing, do it well, and do it only.
34. Extract till you drop! Classes tend to hide inside big functions. To make sure a function does one thing, refactor big functions using Extract Function method, until you cannot extract anymore.
35. Arguments One is OK, two is okish, three is borderline sloppy
36. Arguments A long list of arguments makes it harder to remember what are they doing.
37. Arguments Constructors should follow the same rule. If more than two, maximum three arguments are needed, it might mean that the arguments are cohesive enough to become an object.
38. Arguments No Boolean arguments! Innies, not outies!
39. Switches and cases Switch statements are usually a missed opportunity for polymorphism, and they also tend not to be OOP.
40. Q&A