1. Reviewing Code
A guide to smelling another developer’s source code

2. How much should you review?
Option 1 – All the Code
Option 2 – Parts of the Code
Read through every single line
Attempt to understand the general structure of everything
Read a function
Understand the function
Find other code related to the function
E.g. loading data into a global variable that the function uses
Repeat with another function

3. Review Fewer than 400 LoC (per person)
Your brain can only process so much information at a time
Reviewing more than 400 LoC means you have to keep track of too many variables, functions, classes, etc.
Try to limit yourself to minutes of defect discovery
This is the time you are reading code and writing notes, not writing the actual code review assignment

4. Identifying Problems by Smelling Them
A Code Smell is not a bug
The code works and works correctly
A Code Smell likely indicates a weakness in program design
i.e. The risk of future bugs arising from this smell is high
There are many different kinds of code smell
Refactoring: Improving the Design of Existing Code, by Martin Folwer

5. Long Functions Can Be Bad
If a function is longer than 10 lines of code, it smells
“I just need to add two more lines to this function…”
Repeat the above enough times and your function has grown too large
The longer a function is, the harder it is to:
Read it
Understand it
Maintain it

6. Temporary Variables Can Be Bad
Created for convenience by the programmer early on in the scope
Typically used as in a complex function or algorithm
The temporary variable only receives a real value during some circumstance
Example: within an if-statement
The variables are usually empty (i.e. have no value) or initialized to something meaningless
Harder to debug

7. Example of a Long Function
More Code Here

8. Example of Temporary Variables
If possible, initialize a variable when you declare it.

9. Which scope should variables belong to?
The length variable is only used in the if-statement.
dist, dist_first, and dist_last are used in the else statement.

10. Losing Information on Reassignment
By reassigning these to intersection1/2, we’ve actually lost information.

11. Extraneous Code Do we need to assign the result to length?
Why not return directly?
Do we lose any readability in doing so?

12. Comments Can Be Bad Commenting can help explain unintuitive code
But the code is still unintuitive… can this be fixed?
Some programmers comment out code
There is no reason for this – subversion has a history of all your code
Comments can become out-dated
The code and the comments directly contradict each other
Comments are good if…
They explain why something is coded a certain way
They explain a complex algorithm that is being used

13. Duplicating Code Duplicated Code smells bad because…
It can likely be extracted into its own function
It was likely copy-pasted by the programmer

14. Duplicated Code Example

15. Duplicated Code Example
This code has been copy-pasted. It is clearly duplicate code.

16. Poor Commenting Example
These comments tell the what is about to happen. But they don’t tell me why.

17. Removing Duplication; Adding the Why

18. Learning more About Code Smells
Interactive Website
The Book
Refactoring: Improving the Design of Existing Code
The Taxonomy
Mäntylä, M. V. and Lassenius, C. "Subjective Evaluation of Software Evolvability Using Code Smells: An Empirical Study". Journal of Empirical Software Engineering, vol. 11, no. 3, 2006, pp

19. An (incomplete) C++ Specific Checklist
Does the code compile without warnings?
Are there any expensive copies being made?
Which objects would be expensive to copy?
Are the destructors simple and intuitive?
Is there an excessive use of pointers?
Manual memory management is hard; rely on the STL for most of your dynamic memory allocation
Are variables that can be marked const marked const?

20. A Good Code Review Is specific Cites examples in the code
Is not negative
Don’t be mean, be constructive
Is not opinionated
Not everyone agrees on style and formatting