Clean code
- 2. The total cost of owning a mess
- 9. Meaningful names Method Names Verb or verb phrase
- 10. Meaningful names One word per concept Should be consistent
- 11. Meaningful names Don’t pun Avoid using the same word for two purposes
- 12. Functions
- 14. Functions Do one things Function does one thing if: ● You can describe your function with only one TO paragraph TO RenderPageWithSetupsAndTeardowns, we check to see whether the page is a test page and if so, we include the setups and teardowns. In either case we render the page in HTML. ● You can’t extract function with a name that is not a restatement of implementation
- 15. Functions One level of abstraction per function high getHtml(); intermediate String pagePathName = PathParser.render(pagePath); low .append(“n”).
- 16. Switch statements What is wrong with it? Functions ● Hard to make small ● Does more than one thing ● Violating SRP ● Violating OCP ● Unlimited number of functions with the same structure Use polymorphism and hide switch case to ABSTRACT FACTORY method
- 17. Descriptive names Functions E.g. Method does not only convert to trades. It also unexpectedly validates tradeItems: ● Ward's principle: “You know you are working on clean code when each routine turns out to be pretty much what you expected.” ● Don’t be afraid to make a name long ● Don’t be afraid to spend time on choosing name
- 18. ArgumentsFunctions ● Ideal number of arguments: zero ● Avoid output argument and use return value
- 19. Flag argumentsFunctions Hard to understand: render(true) Change render(boolean isSuite) to renderForSuite(); and renderForSingleTest();
- 20. Argument objects When function has more than two arguments consider to wrap them into a class Functions
- 21. Verbs and KeywordsFunctions assertEquals(expected, actual) to assertExpectedEqualsActual( expected, actual) write(name) to writeField(name)
- 22. Have no side effects Functions E.g. our function mutates validationErrors argument
- 23. Functions Error handling is one thing Extract try/catch block
- 24. Comments
- 25. Comments Good comments: ● Informative ● Explanation of intent ● Clarification
- 26. Comments Good comments: ● Warning of consequences ● TODO ● Amplification of importance ● Javadocs
- 27. Comments Bad comments: ● Noise comments ● Commented out code ● Javadoc in nonpublic code
- 28. Comments Bad comments Don’t use comment when you can use a function or a variable
- 29. Formatting The newspaper metaphor The first paragraph gives you the synopsis of the whole story, hiding the details. As you continue the details increase. Вставьте таблицу или график с результатами
- 30. The law of demeter Method M of object O should only call following methods: ● Methods of Object O itself (because you could talk with yourself) ● Methods of objects passed as arguments to M ● Methods of objects held in instance variable ● Methods of objects which are created locally in method MВставьте таблицу или график с результатами
- 31. Error handling
- 32. Error handling Use unchecked exceptions What price? Open/Closed Principle violation You must declare exception in signature of each method between you and the catch. Signature changes in law level force signature changes on many higher levels
- 33. Error handling Provide context with exceptions Mention the operation that failed and the type of failure to be able to log in catch Define the normal flow to
- 34. Error handling Don’t return null ● Return empty list ● Wrap a null-returning method of third-party with a method returning exception or special case object Don’t pass null
- 35. Boundaries
- 36. Boundaries Using third-party code Encapsulate to protect from changes in third-party code
- 37. Boundaries Learning tests Write some tests to understand third-party code instead of experimenting in production code ● Cost nothing as we have to learn API anyway. ● Verify whether third-party packages work the way we expect them to
- 38. Boundaries Using code which does not yet exist Writing an abstraction keeps client code more readable and focused on what it is trying to accomplish
- 39. Unit Tests
- 40. Unit Tests
- 41. Unit Tests The Three laws of TDD 1. You may not write production code until you have written a failing unit test pass. 1. You may not write any more of a unit test than is sufficient to fail; and not compiling is failing. 1. You may not write more production code than is sufficient to pass the one failing unit test.
- 43. Unit Tests Single concept for test One then per test
- 44. Unit Tests
- 45. Classes
- 46. Classes Classes should be small Class is too large if: ● We can’t derive a concise name (without words Processor, Manager, Super) ● We can’t to write a brief description without “if”, “and”, “or”, “but”
- 47. Classes Single Responsibility Principle = One reason to change Don’t be afraid of navigating through lots of small classes. You code will not have more concepts. This concepts will be more organized.
- 48. Classes Cohesion Maximally cohesive class: each variable is used by each method Strive to “Low coupling high cohesion"
- 49. The Boy Scout Rule Leave the campground cleaner than you found it.
- 50. Literature Clean Code by Robert Martin The Toyota Way by Jeffrey K. Liker