How to perform JavaScript Unit Testing

Following the TDD approach when you are working with MVC it is quite easy to produce Unit Tests that are based on the MVC Controllers, with more and more business logic appearing in the User Interface by using libraries such as jQuery it is becoming more important to perform Unit Testing on JavaScript.

What options are available today, more importantly what are the pros and cons of each solution?

JsUnit

Pros

    can be invoked from an ant build file
    launches browser to run the tests
    Eclipse plug-in

Cons

    launches browser to run the tests
    Does not support js file to write the unit test code: it has to be embedded inside an html file
    it has not been updated for a few years

Notes:

    There is a JsUnit (2).
    An ‘ant’ is an open source build tool; “Ant” because it is a little thing that can build big things.

RhinoUnit

Pros

    ant driven
    supports js file
    very simple to use

Cons

    Simulation of JavaScript engine: not advanced enough to support all coding types

crosscheck

Pros

    Can be invoked from ant build file
    Simulates real browser behaviour

Cons

    Simulation of JavaScript engine from a limited number of browser versions
    No activity for 2 years: it does not support Firefox versions 2.x nor 3.x

jsspec

Pros

    Runs on actual browser

Cons

    JavaScript only framework: cannot be called from ant build file

jspec

Pros

    Runs on actual browser

Cons

    Does not seem to support all code types
    JavaScript only framework: cannot be called from ant build file,

Screw.unit

Pros

    Runs on actual browser

Cons

    JavaScript only framework: cannot be called from ant build file

JSTest

Pros

    Can be intergrated with most testing frameworks, such as MSTest, NUnit, xUnit etc
    ant build supported
    Simple to install, only requires a single dll
    Browserless
    Can be installed using NuGet
    Small overhead of 56k

Cons

    Not very active on CodePlex, with only 51 downloads
    Reference directly to the js files, so if the js files are moved all the tests need to be updated

I know there are many many more and this is just a cross sample of JavaScript testing libraries, but I think I may have found the crown jewels for TDD.

It looks like JSTest is, not only the only choice we have, it is the simplest and best approach to JavaScript Unit Testing, but why has it only had 51 downloads?  Have I found a hidden gem or a monster waiting to bite me?

JSTest does provide an easy way to apply the Test-Driven Development (TDD) process

For an example to use it check out Unit Testing JavaScript with MSTest and JSTest.Net by Shawn Sweeney, I have created a sample MVC application showing it working.

JSTestMVCExample.zip (2.67 mb)

Conclusion, I do think we now have the tools to be fully “TDD” compliant.

JSTest.zip (16.80 kb)

Switching from iPhone to Android

The iPhone is the top smartphone, but some Android rivals like the Galaxy S III are very attractive, and they’re available in large sizes that the iPhone is not. Plus, they support cool technologies Apple doesn’t support.

If you’re ensconced in the Apple fold, you may believe you have to stay all-Apple. It turns out that you can bring Android largely into the Apple ecosystem.

Getting iCloud email

Apple’s iCloud sync and cloud storage service is one of iOS’s and OS X’s key attractions. But Apple keeps it in the family to encourage people to commit. However, you can access iCloud email from the standard Android Email app.

The key is to sign in using your iCloud account’s me.com address, not your icloud.com address. The incoming server is mail.me.com, and the outgoing server is smtp.me.com. SSL should be on.

Syncing iCloud contacts and calendars

iCloud’s auto-syncing contacts and calendars make it supereasy to keep your Mac, iPhone, and iPad up to date with each other. They even work with Windows — but not Android.

That is, unless you buy two utilities for £3.75 each from developer Marten Gajda: Smoothsync for Cloud Calendar and Smoothsync for Cloud Contacts. Both are available in the Google Play app store.

Sign in with your iCloud credentials, and your Android smartphone is now part of the iCloud family. 

Syncing documents

Apple’s iCloud Documents feature in iOS — recently brought to OS X — can be very handy for keeping documents in sync across all devices you use to access or edit them. It’s an Apple-only feature for which there is no way to gain foreign access.

But that’s OK. iCloud Documents is quite limited, requiring the same app on each device to read a particular file type. Many apps in iOS aren’t on OS X, such as OS X’s TextEdit text editor, so iCloud Documents often can’t do the job.

You should use Google Drive or DropBox instead; many iOS apps support them natively, and they work on pretty much every mobile and desktop OS today.

Syncing bookmarks and open URLs

Apple’s Safari 6 in iOS, OS X, and Windows has a neat feature called iCloud Tabs that syncs the URLs of all open tabs to all other devices using Safari 6 tied to the same iCloud account. Bookmarks are also synced across these three OSes.

Again, there’s no way to open up Safari’s iCloud tabs and bookmark syncing to Android — so don’t use Safari. Google’s Chrome browser has a similar sync capability, and it’s available for Android, iOS, OS X, and Windows. (Firefox can also sync across platforms, but recently dropped its iOS sync app; it’s not an option if you’re using an iPad or other iOS device.)

Find a lost or stolen smartphone

Another great iCloud feature is Find My iPhone, which tracks your iOS and OS X devices, so you can find them on a map, send an alert (in case your phone is hidden under a blanket, for example) or message, and lock or wipe them if necessary. Just be sure you set the device so that a thief can’t turn off this feature. Again, Android can’t join in.

But there’s a comparable service called Lookout that lets you find, lock, or wipe a missing Android device from any browser. The basic version is free. However, be warned that it’s easy for a thief to disable it if he or she notices it’s installed.

Syncing with iTunes

One of Apple’s stickiest technologies is iTunes, which is both a library for your entertainment and store from which to get more of it. Google’s free Music Manager app for Windows and OS X syncs nonprotected music wirelessly to your Google Play account, but it must be streamed to your Android device.

A better choice is the free DoubleTwist Player app, which syncs music, videos, and photos. Also, it can transfer these items from iOS device to Android. You need both the Android client and OS X or Windows client. Note that DoubleTwist is full of come-ons for in-app upgrades — annoyingly so. The $5 AirSync add-on is worthwhile, as it allows Wi-Fi syncing between your computer and Android device.

Streaming to AirPlay

Apple TV is an insidiously useful device, acting as a wireless bridge between Macs and iOS devices for screen mirroring and streaming of movies, music, podcasts, and photos. It too is an Apple-only technology.

But the £5 AirSync add-on utility for DoubleTwist lets you stream music and videos from an Android device to the Apple TV, just as if it were an iPhone or iPad. When it works, that is — I often could not get the AirTwist streaming icon to appear, and I never did figure out why.

Managing book libraries

iTunes includes the iBookstore, which lets you buy e-books for reading on the iBooks app on an iPad or iPhone, but iBooks doesn’t work on other devices, not even Macs. Except for the special Multi-Touch e-book format for the iPad, it’s not a great bookstore to use.

Amazon.com’s Kindle app is a better choice, as it works on every major mobile and desktop platform, and its book selection is much larger than Apple’s.

Getting directions

Everyone knows by now that iOS 6’s Apple Maps has major flaws, and Apple has apologized for them. Plus, it provides voice navigation only on an iPhone 4S or iPhone 5. Compare that to Android, whose navigation app has worked well for several years on all Android devices.

But an even better option is the free Waze app; it’s available for both iOS and Android. It provides voice navigation on older iPhones, too.

Getting apps

It’s a cliché, but a true one: In iOS, there’s (very likely) an app for that. Android has a smaller app selection. But you’ll find that content apps and services apps (such as for banking, public transit, and airlines) are almost always available for Android if available for iOS. Ditto for basic utilities such as flashlights, social media, restaurant finders, and bar-code scanners.

Have I gone to the dark side and switched over yet, no, I’m still running my iPhone 4s and Google Nexus 4 together.  So I’m still sitting on the fence, perhaps the Samsung 4 will tip me over, we’ll just have to wait and see.

Disable Shut Down on your Server

When you are connecting via a remote connection to a server I find the Shut Down is far far to close to the log off, and if you hit the Shut Down by mistake it can be a devil to get the remote machine to power back up and may require someone to visit the machine to hit the power button.

You can disable the Shut Down button there is a group policy settings for this, start gpedit.msc on the machine or use a domain policy to configure User Configuration – Administrative templates – Start menu. See the setting “Remove and prevent access to the shut down, restart….”, change it to enabled.

No more shutting down by accident.

How and setup and got my Gadgeteer to work

This is a quick start guide for .NET Gadgeteer and the FEZ Spider Kit. It includes instructions for the installation of necessary software and drivers of the Gadgeteer platform as well as for the first Gadgeteer program. 

Okay so it does not like Visual Studio 2012, so I next need to download is 

1.   Microsoft Visual C# Express 2010
You can still use professional or ultimate.
2.   Microsoft .NET Micro Framework 4.2 QFE2 SDK
This SDK must be installed before step three.
3.   GHI Software Package v4.2 Feb. 18, 2013
Includes NETMF and .NET Gadgeteer SDKs and components. See release notes and known issues.

Should you already have installed C# Express or a full version of Visual Studio 2010. In a second step install the Microsoft .NET Micro Framework 4.2 QFE2 SDK (not 4.1!). You need to create an account on the GHI Electronics website in order to download and install the GHI NETMF v4.2 and .NET Gadgeteer Package in the last step.

First Gadgeteer Application

Run Visual C# Express and create a new Project.

You will start within the hardware layout view. Drag and drop the following modules from the left toolbox onto the white space near the spider mainboard:

  • UsbClientDP module
  • T35_display module
  • Button module

Right click on the white space and select “Connect all modules”. The IDE will automatically connect all your selected modules to compatible ports on the spider mainboard. Now all you need to do is to connect your physical modules the same way. Notice that all sockets on the mainboard as well as on the modules have labels on them (X,Y,U;S, etc.) that describe their compatibility (e.g. socket A modules can only be plugged into A sockets on the mainboard).

Plug the USB mini cable into the UsbClientDB module and connect it with a USB2.0 port on your computer (Hint: USB 3.0 does not work for me!). When  the Spider Kit is connected via USB for the first time, Windows will try to install the driver. If it fails, point the driver installation routine to the following folder (you can find the device as EMX in your system device manager):

C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\USB Drivers\GHI_NETMF_Interface

Select the Program.cs tab which holds the skeleton code for your first Gadgeteer application. Enter the following lines and hit the “Start Debugger” button in the top of Visual Studio:

You can monitor the deployment process in the footer line of Visual Studio. If the process takes too long, try to reset the spider mainboard by pressing the reset button. If deployment is successful a debug window comes up. Press the button module and see what happens on the display. 

FEZSpider Starter Kit Guide.pdf (8.32 mb)

Tinyclr – Gadgeteer First Project

Hacking at its best with DNS

I received a tweet yesterday from @gravax who was the Epic Hack of the Day, so just check this out which is pretty cool

tracert -h 99 216.81.59.173

You get back

12  * * *

13  episode.iv (206.214.251.1)  155.693 ms  161.675 ms  163.572 ms

14  a.new.hope (206.214.251.6)  180.764 ms  171.357 ms  162.435 ms

15  it.is.a.period.of.civil.war (206.214.251.9)  164.476 ms  167.635 ms  155.173 ms

16  rebel.spaceships (206.214.251.14)  170.381 ms  159.131 ms  163.331 ms

17  striking.from.a.hidden.base (206.214.251.17)  155.447 ms  168.457 ms  161.968 ms

18  have.won.their.first.victory (206.214.251.22)  170.991 ms  163.975 ms  156.780 ms

19  against.the.evil.galactic.empire (206.214.251.25)  157.577 ms  161.265 ms  164.181 ms

20  during.the.battle (206.214.251.30)  174.856 ms  166.470 ms  192.210 ms

21  rebel.spies.managed (206.214.251.33)  158.729 ms  172.967 ms  167.352 ms

22  to.steal.secret.plans (206.214.251.38)  168.628 ms  158.817 ms  186.524 ms

23  to.the.empires.ultimate.weapon (206.214.251.41)  158.969 ms  155.680 ms  173.059 ms

24  the.death.star (206.214.251.46)  160.173 ms  179.227 ms  158.865 ms

25  an.armored.space.station (206.214.251.49)  154.652 ms  165.593 ms  159.269 ms

26  with.enough.power.to (206.214.251.54)  165.290 ms  170.299 ms  170.502 ms

27  destroy.an.entire.planet (206.214.251.57)  159.706 ms  163.257 ms  159.500 ms

28  pursued.by.the.empires (206.214.251.62)  159.571 ms  160.371 ms  163.285 ms

29  sinister.agents (206.214.251.65)  173.527 ms  170.109 ms  160.567 ms

30  princess.leia.races.home (206.214.251.70)  158.904 ms  178.839 ms  182.604 ms

31  aboard.her.starship (206.214.251.73)  168.096 ms  158.851 ms  160.790 ms

32  custodian.of.the.stolen.plans (206.214.251.78)  162.274 ms  171.099 ms  231.641 ms

33  that.can.save.her (206.214.251.81)  168.688 ms  167.075 ms  169.212 ms

34  people.and.restore (206.214.251.86)  160.793 ms  157.587 ms  161.663 ms

35  freedom.to.the.galaxy (206.214.251.89)  178.962 ms  154.471 ms  160.194 ms

36  0——————-0 (206.214.251.94)  159.720 ms  157.607 ms  165.869 ms

37  0——————0 (206.214.251.97)  161.146 ms  174.066 ms  161.739 ms

38  0—————–0 (206.214.251.102)  166.029 ms  164.294 ms  160.558 ms

39  0—————-0 (206.214.251.105)  190.757 ms  166.709 ms  186.424 ms

40  0—————0 (206.214.251.110)  157.325 ms  158.420 ms  181.166 ms

41  0————–0 (206.214.251.113)  160.496 ms  158.207 ms  160.479 ms

42  0————-0 (206.214.251.118)  161.534 ms  168.666 ms  157.581 ms

43  0————0 (206.214.251.121)  157.866 ms  159.754 ms  167.938 ms

44  0———–0 (206.214.251.126)  163.660 ms  179.243 ms  163.206 ms

45  0———-0 (206.214.251.129)  168.475 ms  163.112 ms  158.493 ms

46  0———0 (206.214.251.134)  157.329 ms  158.661 ms  161.612 ms

47  0——–0 (206.214.251.137)  161.833 ms  164.059 ms  166.384 ms

48  0——-0 (206.214.251.142)  169.368 ms  182.151 ms  161.276 ms

49  0——0 (206.214.251.145)  172.806 ms  159.547 ms  169.672 ms

50  0—–0 (206.214.251.150)  165.376 ms  156.775 ms  169.386 ms

51  0—-0 (206.214.251.153)  157.625 ms  163.558 ms  162.880 ms

52  0—0 (206.214.251.158)  179.708 ms  167.693 ms  159.625 ms

53  0–0 (206.214.251.161)  158.662 ms  163.736 ms  170.034 ms

54  0-0 (206.214.251.166)  160.455 ms  162.898 ms  172.839 ms

55  00 (206.214.251.169)  171.892 ms  181.111 ms  157.887 ms

56  * i (206.214.251.174)  165.980 ms  173.152 ms

57  by.ryan.werber (206.214.251.177)  166.216 ms  160.726 ms  165.419 ms

58  when.ccies.get.bored (206.214.251.182)  175.014 ms  180.888 ms  159.231 ms

59  ccie.38168 (206.214.251.185)  164.865 ms  166.514 ms  183.855 ms

60  fin (216.81.59.173)  169.747 ms  165.412 ms  165.241 ms

 
How did Ryan Werber do it?

Star Wars Traceroute

“Bored in the blizzard in Boston; I was inspired by my IRC friend ‘Plazma’ constantly making fun of my reverse dns of scrye.net I came up with this pretty neat hack.
 
It is accomplished using many vrfs on (2) Cisco 1841s. For those less technical, VRFs are essentially private routing tables similar to a VPN. When a packet destined to 216.81.59.173 (AKA obiwan.scrye.net) hits my main gateway, I forward it onto the first VRF on the “ASIDE” router on 206.214.254.1. That router then has a specific route for 216.81.59.173 to 206.214.254.6, which resides on a different VRF on the “BSIDE” router. It then has a similar set up which points it at 206.214.254.9 which lives in another VPN on “ASIDE” router. All packets are returned using a default route pointing at the global routing table. This was by design so the packets TTL expiration did not have to return fully through the VRF Maze. I am a consultant to Epik Networks who let me use the Reverse DNS for an unused /24, and I used PowerDNS to update all of the entries through mysql. This took about 30 minutes to figure out how to do it, and about 90 minutes to implement. All VRFs and DNS were generated by a PHP script. Disclaimer: I am not a very elegant programmer. I can do whatever I need to. I think very linearly and do not plan very well. Below is the code I used to generate the VRFs.”
 
 

Avoid, Find and Fix ASP.NET Performance Issues

Following on from my articles on producing smarter code I have come across “50 ways to Avoid, Find and Fix ASP.NET Performance Issues” by RedGate, won’t say it is the best advise but still gives some good tips on how to improve performance.

50 ways to Avoid, Find and Fix ASP.NET Performance Issues

50 Ways to Avoid, Find and Fix ASP.NET Performance Issues.pdf (1.22 mb)

Missile Launcher

Time to get tough and have a bit of fun…..

This small project came about when team members kept breaking the builds on our build server, and as a result causing compile errors for other developers when they wanted to work on the latest code.

So with a plan in mind I set to task in resolving this issue, first I needed to raise peoples attention that something has gone wrong, so what can I use to do this?

I could use a flashing light, a siren, both would draw attention, but it these would just signal that something has gone wrong.  I need something that will not only signal that something has gone wrong but will also seek out, wait I know the solution a Missile Launcher, both physical and I could get it to fire at the developer who has failed….!  Perfect

I need to find a Missile Launcher that I could programme, and I found one:

Dream Cheeky has the perfect launcher.

So after paying $34.99 and it being shipped from Hong Kong, it arrived about a week later

Next to download the drivers and software from Dream Cheeky, it was not long I had my missiles firing across my room.

Okay now let’s get hacking.

I found in the “C:\Program Files (x86)\Dream Cheeky\STORM O.I.C. Missile Launcher” directory a file called USBLib.DLL, so I tried to reference Visual Studio to this file, hay presto it connects, first step completed.

Let try and connect to the DLL from within Visual Studio

So load up the MissileLauncher.cs below and you have an API

Storm_setup.exe (7.18 mb)

MissileLauncher.cs (4.67 kb)

Next step is to interface to Team Foundation Server and detect failed builds, watch this space for the next steps

Code Review Guidelines

What is a code Review?

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. 

Why Reviews are important?

Quoting from Code Complete:

.. software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.

In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.

The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.

IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.

A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.

Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.

The main goals of code review are:

  1. To spot and fix defects early in the process.
  2. Better-shared understanding of the code base as team members learn from each other
  3. Helps to maintain a level of consistency in design and implementation.
  4. Helps to identify common defects across the team thus reducing rework.
  5. Builds confidence of stakeholders about technical quality of the execution.
  6. Uniformity in understanding will help interchangeability of team members in case of non-availability of any one of them.
  7. A different perspective. “Another set of eyes” adds objectivity. Similar to the reason for separating your coding and testing teams, peer reviews provide the distance needed to recognize problems.
  8. Pride/reward. Recognition of coding prowess is a significant reward for many programmers.
  9. Team cohesiveness. Working together helps draw team members closer. It also provides a brief respite from the isolation that coding often brings.

The main areas a reviewer is focusing on are as follows:

  • General Unit Testing
  • Comment and Coding Conventions
  • Error Handling
  • Resource Leaks
  • Thread Safety
  • Control Structures
  • Performance
  • Functionality
  • Security

Roles and Responsibilities

  • The Developer is the person who has written the code to be reviewed and has initiated the review request.
  • The Reviewer/s: are the people who are going to review the code and report the findings to the developer.
Like any skill, good peer reviews come with practice. Some tips that should help you get started on the right track are as follows:
Tips for the Developer:
  1. The primary reviewer is the author i.e. YOU.
  2. Create a checklist for yourself of the things that the code reviews tend to focus on. Some of this checklist should be easy to put together. It should follow the outline of the coding standards document. Because it’s your checklist, you can focus on the thing that you struggle with and skip the things that you rarely, if ever, have a problem with. Run through your code with the checklist and fix whatever you find. Not only will you reduce the number of things that the team finds, you’ll reduce the time to complete the code review meeting—and everyone will be happy to spend less time in the review.
  3. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
  4. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
  5. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
  6. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
  7. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
  9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
  10. Please note that Review meetings are NOT problem solving meetings.
  11. Help to maintain the coding standards. Offer to add to the coding standards for things discussed that aren’t in the coding standards. One of the challenges that a developer has in an organization with combative code review practices is that they frequently don’t know where the next problem will come from. If you document each issue into the coding standards, you can check for it with your checklist the next time you come up for code reviews. It also will help cement the concept into your mind so that you’re less likely to miss opportunities to use the feedback.

 Tips for the Reviewer

  1. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
  2. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
  3. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
  4. Please note that Review meetings are NOT problem solving meetings.
  5. Ask questions rather than make statements. A statement is accusatory. “You didn’t follow the standard here” is an attack—whether intentional or not. The question, “What was the reasoning behind the approached you used?” is seeking more information. Obviously, that question can’t be said with a sarcastic or condescending tone; but, done correctly, it can often open the developer up to stating their thinking and then asking if there was a better way.
  6. Avoid the “Why” questions. Although extremely difficult at times, avoiding the”Why” questions can substantially improve the mood. Just as a statement is accusatory—so is a why question. Most “Why” questions can be reworded to a question that doesn’t include the word “Why” and the results can be dramatic. For example, “Why didn’t you follow the standards here…” versus “What was the reasoning behind the deviation from the standards here…”
  7. Remember to praise. The purposes of code reviews are not focused at telling developers how they can improve, and not necessarily that they did a good job. Human nature is such that we want and need to be acknowledged for our successes, not just shown our faults. Because development is necessarily a creative work that developers pour their soul into, it often can be close to their hearts. This makes the need for praise even more critical.
  8. Make sure you have good coding standards to reference. Code reviews find their foundation in the coding standards of the organization. Coding standards are supposed to be the shared agreement that the developers have with one another to produce quality, maintainable code. If you’re discussing an item that isn’t in your coding standards, you have some work to do to get the item in the coding standards. You should regularly ask yourself whether the item being discussed is in your coding standards.
  9. Remember that there is often more than one way to approach a solution. Although the developer might have coded something differently from how you would have, it isn’t necessarily wrong. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that’s all you can ask for.
  10. You shouldn’t rush through a code review – but also, you need to do it promptly. Your coworkers are waiting for you.
  11. Review fewer than 200-400 lines of code at a time.

Security Code Review

If the applications requires a very close attention to security then www.owasp.org is the right place for resources. This is a very good Security Code Review document to consider: https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf

Assign Severity to Review Finding

The severity to find issues with code should go as below. Reviewer must focus on issues with High severity first and then to Medium severity and then Low severity issues.
  1. Naming Conventions and Coding style = Low
  2. Control Structures and Logical issues = Medium or High
  3. Redundant Code = High
  4. Performance Issues =High
  5. Security Issues = High
  6. Scalability Issues= High
  7. Functional Issues =High
  8. Error Handling = High
  9. Reusability = Medium
  10. Checklist for developers and reviewers
Checklists are a highly recommended way to find the things you forget to do, and are useful for both authors and reviewers. Omissions are the hardest defects to find – after all, it’s hard to review something that’s not there. A checklist is the single best way to combat the problem, as it reminds the reviewer or author to take the time to look for something that might be missing. A checklist will remind authors and reviewers to confirm that all errors are handled, that function arguments are tested for invalid values, and that unit tests have been created.
Another useful concept is the personal checklist. Each person typically makes the same 15-20 mistakes. If you notice what your typical errors are, you can develop your own personal checklist. Reviewers will do the work of determining your common mistakes. All you have to do is keep a short checklist of the common flaws in your work, particularly the things you forget to do. As soon as you start recording your defects in a checklist, you will start making fewer of them. The rules will be fresh in your mind and your error rate will drop. We’ve seen this happen over and over.

Checklist for Developers

  • My code compiles
  • My code has been developer-tested and includes unit tests
  • My code is tidy (indentation, line length, no commented-out code, no spelling mistakes, etc)
  • I have considered proper use of exceptions
  • I have made appropriate use of logging
  • I have eliminated unused usings’
  • I have eliminated warnings
  • The code follows the Coding Standards
  • Are there any leftover stubs or test routines in the code?
  • Have I use Separation of Concerns and interface where possible?
  • Are there any hardcoded, development only things still in the code?
  • Was performance considered?
  • Was security considered?
  • Does the code release resources? (HTTP connections, DB connection, files, etc)
  • Corner cases well documented or any workaround for a known limitation of the frameworks
  • Can any code be replaced by calls to external reusable components or library functions?
  • Thread safety and possible deadlocks

Checklist for Reviewers

  • Comments are comprehensible and add something to the maintainability of the code
  • Comments are neither too numerous nor verbose
  • Types have been generalized where possible
  • Parameterized types have been used appropriately
  • Exceptions have been used appropriately
  • Repetitive code has been factored out
  • Frameworks have been used appropriately – methods have all been defined appropriately
  • Command classes have been designed to undertake one task only
  • The presentation layer do not contain business logic
  • Unit tests are present and correct
  • Common errors have been checked for
  • Potential threading issues have been eliminated where possible
  • Any security concerns have been addressed
  • Performance was considered
  • The functionality fits the current design/architecture
  • The code is unit testable
  • The code does not use unjustifiable static methods/blocks
  • The code complies to coding standards
  • Logging used appropriately (proper logging level and details)