code review

Code Review

What is it ?

code review is a special kind of inspection in which the team/member examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved.

And why ?

It's one of the best ways to ensure good code quality and provides an excellent way to share domain knowledge with team members who may otherwise not get the opportunity.It also allows experienced developers to share their knowledge and ideas with less experienced developers, an excellent way of distributing development skills across an entire team.

And why ?

Code quality increases as the number of support calls decreased and the number of reported bugs decreased as well.The benefits of code review can be a more stable product, more maintainable code as it applies to structure and coding standards, and it allows developers to focus more on new features rather than “fire-fighting” bugs, and other production issues.

And Why ?

Finds and fixes maintain ability issues such as documentation, organization, architecture, usability, efficiency, robustness, maintainability, and portability. All of these things affect overall code quality

Makes engineers more familiar with parts of the code base they might never see otherwise, breaking down the “my code/your code” silos and giving your engineering team much broader exposure to the entire codebase.

Issues ...

Never Following Through:The author simply takes no notice of the comments or suggests

Issues ...

Lack of Buy In:This is one of the hardest hurdles to overcome.When a team simply doesn’t buy-in to the idea of code reviews, it will be difficult to get anything useful out of a review

Issues ...

Talking Unrealistic Expectations:

If ( (int)$x > (int)$y)

{

// do something

}

If $x=2323223232323232325656 and $y=5 The maximum value depends on the system. 32 bit systems have a maximum signed integer range of -

2147483648 to 2147483647. So for example on such a system, intval('1000000000000') will return 2147483647. The maximum signed integer value for 64 bit systems is 9223372036854775807

Issues ...

Peer Fear: :-) so many reasones ...

Big Brother is now watching and grading me on my defects!

Code review takes time we don’t have, and we’ll miss our deadline!

etc ...

Solutions?

It’s not always easy ....

Code Review Types

Over-the-shoulder: One developer looks over the author's shoulder as the latter walks through the code.

Email pass-around: The author emails code to reviewers.

Pair Programming: Two authors develop code together at the same workstation.

Tool-assisted: Authors and reviewers use specialized tools designed for peer code review.

Peer Review

An activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities.Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities.

Peer Review...

If you don't understand a function orIf you don't understand a function ormethod in 30 seconds, it is probablymethod in 30 seconds, it is probablytoo complextoo complex

It's easy to code for computers,It's easy to code for computers,but hard to code for humansbut hard to code for humans

Peer reviews can take many forms

An inspection: is the most systematic and rigorous type of peer review. Inspection follows a well-defined multistage process with specific roles assigned to individual participants. Inspections are more effective at finding defects than are informal reviews.

Team reviews: are a type of “inspection-lite,” being planned and structured but less formal and less rigorous than inspections. Typically, the overview and follow-up inspection stages are simplified or omitted, and some participant roles may be combined (e.g., moderator and reader).


A walkthrough: is an informal review in which the work product’s author describes it

to some colleagues and solicits comments. Walkthroughs differ significantly from

inspections because the author takes the dominant role; other specific review roles are

usually not defined. Walkthroughs are informal because they typically do not follow a

defined procedure, do not specify exit criteria, require no management reporting, and

generate no metrics.

In pair programming: two developers work on the same program simultaneously at a

single workstation, continuously reviewing their joint work. Pair programming lacks

the outside perspective of someone who is not personally attached to the code that a

formal review brings.


In a peer deskcheck: only one person besides the author examines the work product.

A peer deskcheck typically is an informal review, although the reviewer could

employ defect checklists and specific analysis methods to increase effectiveness.

A passaround: is a multiple, concurrent peer deskcheck, in which several people are

invited to provide comments. The passaround mitigates two major risks of a peer

deskcheck: the reviewer failing to provide timely feedback and the reviewer doing a

poor job.

Better code .. code/review - 1

All of the participants in a review should avoid personally attacking the person being reviewed with statements such as “why did you do it that way?” or “what were you thinking?” etc. These types of comments diminish the trust between peers, leading to animosity, hours of arguing over the best/right way to code a solution. Keep in mind that developers do not think or code exactly the same, and there are many solutions to a problem. Just a little clarification on over-the-shoulder reviews; these can be conducted via remote desktop sharing (pick flavor here), or in person. However, they shouldn’t be limited to the developers only.


Consistently Format Source Code

Format source code consistently Establish a coding standard How to indent Where to put whitespace Capitalization Reuse existing coding standards


Create API Documentation (Use Trac wiki or any other centrlized place where each developer can easily go and understand documentation about module or code)

Use PHPdoc (if you have put proper inline commenting in code)

Special @tags

(@author, @version, @param,@returns, …etc)


Eliminate Redundant Code

Avoid duplicate or similar code The Goal is: Make code changes in just one spot Create parametrized functions and methods (“helper functions”) Do not over-generalize when programming, use Refactoring


Shorten Code Blocks

Break down code into little pieces A method or function should fit on the screen without scrolling When the code needs (too many) inline comments, it may be too

complex No more than three nesting levels


Replace Implementations ...

Use native PHP instead of an old extension Use components (PEAR,SPL,ezComponents

etc.) Use PHP extensions(XMLWriter, SOAP)


Refactoring Changing code to improve readability Changing code to simplify the structure Without changing the results Not adding new functionality 'Clean Up' the code Improve the design


Why Refactor ?

The world constantly changes environment changes terminology changes requirements change

Software design decays over time We never get things right the first time


When To Refactor ..

Before you add new functionality Refactor until it becomes obvious how to add a

feature When you don't understand the code Make code more readable When you fix a bug After a code review


xUnit Framework for PHP PHPUnit (www.phpunit.de) SimpleTest (www.simpletest.org) Not only for object-oriented code If you don't have tests, create them as you go At least, run a Lint check:

php -l <filename> find ./ -type f -name \*.php -exec php -l {} \; |

grep "Errors parsing "; //-not -regex '.*/.svn/*.*'


Tools:-

1.Trac

2.php_beautifier[php_beautifier -l "Pear(add_header=apache) ArrayNested() ListClassFunction()" index.php index_new.php]

3.phpcpd

4.phploc[phploc --count-tests /usr/local/src/ezcomponents/trunk/Workflow]

5.phpdcd

6.phpmd [phpmd /path/to/source text codesize,unusedcode,naming]

7.statsvn[java -jar statsvn.jar searchAgents/logfile.log searchAgents/ -output-dir svnreport/]


Always check Performance … YSlow (Firefox)

PageSpeed (Firefox)

Firebug (Firefox)

HTTPWatch (Firefox & IE)

Dynatrace Ajax Edition (IE only, Firefox beta)

xdebug netstat -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn ps -e -o vsz | awk '{size += $1}END{print(size)}' mpstat -P ALL 5 vmstat 5

Summary

We look at things like:- coupling cohesion thread safety (if threads were used) Boundary Conditions (what is going into and out of a method is what you expect e.g. no nulls) Code style follows company standards Code is not duplicated or copied (this can be automated Google for Simian) Code complexity - Google cyclomatic complexity Will the code that has been written cause any knock ons in other parts of the system If class, method and variable names are kept meaningful a lot of comments should not be

necessary Is exception handling in place and comply with company standard There are Unit Tests for the code that are meaningful and the tests are relevant Logic errors Conformance to the specification (you have one of those, right?) Robustness/defensive programming Failure notification

Thank You

Resourses/Links:

http://leewinder.co.uk/blog/?p=763 http://www.stellman-greene.com/aspm/content/view/33/40/ http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html http://www.processimpact.com/articles/seven_truths.pdf http://smartbear.com/white-paper.php?content=docs/articles%2FFour-Kinds-Of-Review.html http://www.processimpact.com/reviews_book/reviews_book.shtml http://css.dzone.com/articles/automated-code-reviews-php http://joseantony.com/2010/12/04/php-code-review-checklist/ http://www.stellman-greene.com/2008/09/20/how-to-hold-a-more-effective-code-review/ http://www.stellman-greene.com/aspm/content/view/33/40/ www.refactoring.com http://c2.com/cgi/wiki?WhatIsRefactoring http://mindprod.com/jgloss/unmain.html

code review

Education

peer code review

benefits of code review

maintainable code

code base

sample of code

block of code

better code

peer review methods