coding: styles, reviews, and metrics · coding styles code is more often read than written....

Coding: Styles, Reviews, and Metrics

CSC 440/540: Software Engineering Slide #1

Topics

1. Technical Debt

2. Coding Styles

3. Code Reviews

4. Going Further


Technical Debt

Technical debt is the extra development work that

arises when code that is easy to implement in the short

run is used instead of writing the best overall solution.

Sources of technical debt

Business pressures.

Lack of process.

Lack of a test suite.


Cost of Technical Debt


Technical Debt Quadrant


Coding Styles

Code is more often read than written.

Optimize for readability.

By all programmers on your team.

Readability is a superset of consistency.

Pick a coding style then use it consistently.

2 vs. 4 vs. 8 character tabs don’t matter; just pick one.

Publish and automate coding styles

Publish a coding style document.

Use tools (gofmt, indent) to automate formatting.


Coding Style Guides

Google Guides

https://github.com/google/styleguide

Oracle/Sun Java Style Guide

http://www.oracle.com/technetwork/java/javase/docum

entation/codeconvtoc-136057.html

Python Style Guide (PEP-8)

https://www.python.org/dev/peps/pep-0008/

Community Ruby Style Guide

https://github.com/bbatsov/ruby-style-guide


https://github.com/google/styleguidehttp://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Naming

Use names that reveal intentions

Use fileAgeInDays instead of just days.

Use searchable names

This is an important reason to name constants too.

Pick one word per concept

Choose one from synonyms like fetch, get, retrieve.

Object-oriented names

Use nouns to name classes.

Use verbs to name methods.


Code Reviews

Inspection of source code by one or more people who

aren’t the author of the code.

Goal: Identify defects for later removal.

People: Moderator, reviewers.

Scope: Module or small set of classes.

Time: 1-2 hours;

Benefits of Code Reviews

1. Find defects sooner in the lifecycle.

(IBM finds 82% of defects before testing.)

2. Find defects with less effort than testing.

(IBM—rev: 3.5 hrs/defect, test: 15-25 hrs/defect.)

3. Find different defects than testing.

(Can identify design and requirements problems too.)

4. Educate developers about security bugs.

(Developers frequently make the same mistakes.)


Resistance to Code Reviews

Perceived Cost

Takes time to prepare materials and review them.

Adds meetings to schedule.

Programmer Fears

Fear of having other people read their code.

Fear of being blamed for mistakes.

Fear of investing time in other developer’s code.

Fear of missing deadlines due to time spent on reviews.


Inspections

Most formal process.

Thorough coverage with separated roles.

Use checklists to focus on specified goals.

Collect metrics to track defects.

Determine whether further inspections of revised

software needed at end of meeting.

Extensive documentation of effectiveness.

One study found 16-20 defects/kloc with inspections

compared with 3 defects/kloc in informal walkthrough.


Roles in Reviews

1. Moderator

Manages meeting; follows up on issues.

2. Reader

Paraphrases code during meeting.

Not the author.

3. Recorder

Records bugs discovered.

4. Author

Provides context for code; answers questions.

Makes corrections after code review.


Walkthroughs

Less formal process.

Author leads meeting and describes code.

Focus on author needs, not quality goals.

No checklists used or metrics gathered.

Quality varies widely.

Walkthrough quality depends solely on author.

Useful for educating developers about code, provide high

level view of design and defects.


Code Review Process

Planning

Author

Moderator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-up

Author

Moderator


Planning

1. Author initiates Planning once code ready.

2. A Moderator is assigned to inspection.

3. Author and Moderator assemble inspection pkg.

4. Moderator identifies other participants.

Planning

Author

Moderator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-up

Author

Moderator


Preparation

1. Reviewers examine inspection package.

2. Reviewers use checklists and analysis tools.

3. Reviewers mark bugs found.

Planning

Author

Moderator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-up

Author

Moderator


Meeting

1. Reader describes code in own words.

2. Reviewers comment and ask questions.

3. Recorder notes all potential bugs, suggestions.

4. Team appraises code at meeting conclusion.

Planning

Author

Moderator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-up

Author

Moderator


Rework

Author addresses issues recorded at meeting.

Planning

Author

Moderator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-up

Author

Moderator


Follow-up

1. Moderator meets with Author about rework.

2. Moderator verifies all changes made correctly.

3. Author checks in corrected code.

Planning

Author

Moderator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-up

Author

Moderator


Code Review Tips

1. Do small and frequent code reviews.

Typical review speed is 150-200 lines/hour

2. Know what bugs to look for.

Checklists

Static analysis tools

3. Use tools.

Simple tools: grep, findstr

Code viewers

Static analysis tools

4. Require preparation before the meeting.


ChecklistsCode reviews should include checklists ofcommon problems, including:

1. SQL injection

2. Cross-site scripting

3. Input validation bugs

4. Checking return values

5. Resource name canonicalization

6. Race conditions


Code Review Problems

1. Requires substantial expertise in area of

programming and security to be effective.

2. Human readers are fallible and will miss mistakes.

3. Code reviews take time. Unreviewed legacy code can

take an enormous amount of time to handle, so you

need a way to prioritize which code to review.


Prioritizing Code

If you can’t review everything, review

Code that runs with privileged mode.

Code that listens on globally accessible sockets.

Code that is accessible w/o authentication.

Code with a history of vulnerabilities.

Code that handles sensitive data.

Complex code.

Code that changes frequently.


Reviewing for SQL Injection


Ex: Zune infinite loop on 12/31/08

year = 1980;

while (days > 365) {if (IsLeapYear(year)) {

if (days > 366) {days -= 366;year += 1;

}} else {

days -= 365;year += 1;

}}


Going Further


References

1. Martin Fowler, “Technical Debt Quadrant,” http://martinfowler.com/bliki/TechnicalDebtQuadrant.html, 2009.

2. Michael Howard, “A Process for Performing Security Code Reviews.” IEEE Security & Privacy, July 2006.

3. Eoin Keary et. al., OWASP Code Review Guide 1.1, http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project, 2008.

4. Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008.

5. Steve McConnell, Code Complete, 2/e, Microsoft Press, 2004.

6. Karl Wiegers, Peer Reviews in Software, Addison-Wesley, 2002.

http://martinfowler.com/bliki/TechnicalDebtQuadrant.htmlhttp://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

coding: styles, reviews, and metrics · coding styles code is more often read than written....

Documents