Code Practices
- 2. HELLO! I am Victor Matyushevskyy
- 3. MEET BOB
- 5. 75 PERCENTSThat much information we percieve though sight How your code looks matters
- 6. A way to better looking code • Consistent Code Indentation • Consistent Members Ordering • Avoid Deep Nesting • Use Access Modifiers • Limit Line Length
- 7. BAD STYLE
- 8. BAD STYLE
- 9. GOOD STYLE
- 10. GOOD STYLE
- 12. Reasons for using a convention • Reduce the effort needed to read and understand source code • Provide additional information about identifier usage • Provide better understanding in case of code reuse after a long interval of time • Help avoid "naming collisions" • Enable code reviews to focus on more important issues • Enhance the aesthetic and professional appearance of work product
- 13. Let’s compare this typical code: float a, b, c; a=9.81; b=5; c=0.5*a*(b^2); To this self-documenting code: const float gravitationalForce = 9.81; float timeInSeconds = 5; float displacement = (1 / 2) * gravitationalForce * (timeInSeconds ^ 2);
- 14. Naming Styles Pascal Case DijkstraResult ReconstructShortestPath(Graph graph, Vertex startVertex) Camel Case DijkstraResult reconstructShortestPath(Graph& graph, Vertex& startVertex) Underscore Case def reconstruct_shortest_path(predecessors, start_vertex, end_vertex)
- 16. Comments. Use them to… • Describe code that might be difficult for someone to follow • In cases of extreme optimization when using advanced techniques • If you take an approach that might not be obvious to others • Mark places of code that must be unchanged for a reason • Describing why things are done the way they are, not how they work
- 17. Commentaries Conventions • Splitting long comments into multiple line comment • Avoid obvious comments • Place the comment on a separate line, not at the end of a line of code. • Begin comment text with an uppercase letter • Insert one space between the comment delimiter and the comment text
- 18. Let’s compare this example of a poor commenting style: const float a = 9.81; //gravitational force float b = 5; //time in seconds float c = (1/2)*a*(b^2) //multiply the time and gravity together to get displacement And this documented code, which better explains why it is being done : // Compute displacement with Newton's equation x = vₒt + ½at². const float gravitationalForce = 9.81; float timeInSeconds = 5; float displacement = (1 / 2) * gravitationalForce * (timeInSeconds ^ 2);
- 19. 4. CODE SMELL
- 20. CODE SMELL • Usually is not a bug • Does not prevent the program from functioning • Indicates weaknesses in design • Might increase risks of a bug in future
- 21. BLOATERS Long Methods Long Parameter List Large Class
- 22. OBJECT-ORIENTATION ABUSERS Switch Statements Temporary Field Refused Bequest
- 23. CHANGE PREVENTERS Divergent Change Shotgun Surgery Parallel Inheritance Hierarchies
- 24. DISPENSABLES Speculative Generality Duplicate Code Comments
- 25. COUPLERS Feature Envy Message Chains Middle Man
- 26. 5. CODE REVIEW
- 27. NO REVIEW
- 28. WHAT FOR? • Improves code quality • Detects code smells • Checks for styles and conventions • Knowledge sharing
- 29. TWO TYPES OF REVIEW Design Review Analysis of design and architecture of application. Code Review Analysis of written code, conventions and styles.
- 30. CODE REVIEW PROCESS Request Review Review Comments Refactor Close Review Repeat
- 32. LET’S REVIEW SOME CONCEPTS Layout The way your code is structured is the way it is perceived. Names Choosing a better name for variables or type members is a step towards readability. Comments Less of them makes you concentrate on code itself. Use them wisely. Smell Like a rotten apple, youre code can smell, so keep it fresh and clean. Review One head is good, two is better. Reviewing you code can detect potential bugs and gaps. Conventions Before writing some code know what convetions to use to keep code hygiene consistent.
- 34. eleks.com Inspired by Technology. Driven by Value.