Viewing entries tagged

1 Comment

Must-Have Visual Studio Extensions

I'm just setting up a new dev box now and there are always some things, like extensions and tools, I feel they are a must-have for Visual Studio 2010 devs. Some of these extensions like the Web Essentials have already made it to Visual Studio 11 (still in Beta), but I still wanted to share my preferences for my must have VS extensions:
  1. ReSharper
  2. NuGet Package Manager
  3. Productivity Power Tools
  4. Web Essentials
  5. Image Optimizer
  6. Javascript Parser

There is a cool Channel 9 vid where Mads Kristensen does a walkthrough of some of the goodies in his Web Essentials and the Image Optimizer. If you are in the web dev space, you should check it out:

1 Comment


Configuring ReSharper Code Analysis

This article is supporting the article "Definition of DONE" with regards of code cleanup.

Having your code CLEAN is not only elegant, but also a good practice and habit to have specially if you work in a team environment. Every developer have their own styles, likes and dislikes when it comes to code formatting, ordering, grouping regions, etc; precisely because of this, is always good to get the team together, crack-open some Red Bulls and come up with your code standards and practices (and while you are at it, put them up on the Wiki). You can then use automation tools for your IDE to speed up the process and make sure everybody is generating and organizing their code files using the same rules. In my case, at work, we are living in the .NET world and ReSharper 4 or later in Visual Studio does the trick perfectly for us.

ReSharper has a feature called "Code Cleanup" that accomplishes exactly that: it automates the suggestions from the "Code Analysis" and applies them to code files. You can remove code redundancies, reorder type members and remove redundant using directives among many other things. This is not the only one of the many useful things ReSharper offers to .NET developers, but is certainly one I use the quite often. Let's see how it works.

At the time of this article I'm using VS 2010 and ReSharper 5.0, so all images are representative only of such software and version.

Make it perfect in one machine

The first thing is to configure all the settings in ReSharper on one machine and then share your settings. There is plenty to go through and each team may have different requirements. For example, by default ReSharper has the inspection severity on the unit "Redundant 'this.' qualifier" to "Show as warning" and in my team WE DO LIKE to use the 'this.' qualifier regularly, so we changed the R# setting to make "Show as hint". Things of this magnitude does not impact performance in code execution, the compiler simply ignores it; and they are more of a "style" type of inspection you can always tailor to your specific needs.

Once you have your Dev Box all configured, simply export your settings so the rest of the team can use them.

You can download the style we are currently using HERE.

That is the official way of sharing things using ReSharper, BUT... there is a small problem: that only shares the code inspection rules of the ReSharper settings and not other[important] things like the "Code Cleanup" settings. Breathe with ease ninja, there are solutions.

  1. If you have ReSharper 5.1 => you can use Resharper Setting Manager. This is an open source tool (CodePlex hosted) that allows you share ALL of your R# settings very easily. Officially you need R# 5.1 for this tool; I've tried it with R# 5.0 and have had a success rate of 0.5 (there is some black magic going on there that makes it work only half of the time with R# 5.0).
  2. Go old school and just copy the settings straight from the application data on your installation folder. Just navigate to  %appdata%JetBrainsReSharperv5.0vs10.0 and copy the files UserSettings.xml and Workspace.xml to your repository (or a share folder, or email, or... ). You can then get those settings from other dev machines and put them in their respective places (close VS first).

Now when you open VS on the other dev machines you'll find the same configuration and code cleanup settings as the original box. Sweet!

Using Code Cleanup

When using VS with a source code file open, the code inspection engine will always notify you of how well (clean) your code is doing with regards to your R# settings. The keyboard shortcut to run the code clean up is Ctrl+E+C or Ctrl+K+C depending on the shortcut schema layout you are using. After you run it, things will be looking better for you ;)

  • Red light means there is a BREAKING change on the code, and will probably not compile.
  • Orange light means the code doesn't have any breaking changes, but it can be improved. You'll get some warnings and some suggestions.
  • Green means you are good to go buddy. Ready for commit.

Part of our Definition of DONE is to get a green light on your source files. No exceptions.

You can find some more useful features of ReSharper like solution-wide analysis HERE.



Definition of "DONE"

I've been using SCRUM to manage my team for sometime now. When a new member joins the team one of the first things to get him/her up to speed is to get them aquainted with the team definition of "DONE". So here we go. When thinking whether or not a work item is "Done", ask yourself "Is this feature ready to be shipped?" if the answer is not a STRONG yes, then it is very likely the work is not "Done".

One basic principle we can follow when developing features and trying to complete work is:


-> "Done" != "Done Enough"

-> "Done" = Shippable

A developer can say a work item is "Done" when:

  1. The case have specification and an entry with the specification in FogBugz (we use FogBugz for issue and bug tracking)
  2. The item was planned, designed and had an estimate (in time).
  3. Coding completed
  4. Code clean-up:
    • ReSharper is showing a green box in the code formatting column (HOW?).
    • FX Cop shows 0 warnings (HOW?).
    • Unnecessary commentaries removed
    • All TO-DO sections were removed
  5. Code was commented and checked-in
  6. Peer-to-Peer review happened
    • Coding standards and code quality
    • Code security review
  7. Hallway usability tested
  8. Unit tested (when there is a unit test sub-case)
  9. Documentation
    1. Wiki: Always have a wiki page documenting your feature and the components involved in it, like what tables, folders, configuration elements, etc.
    2. Release Notes: When configuration or deployment instructions change, it must be documented.
    3. Item was signed off by appropriate personnel and the FogBugz case was closed.

Some Rules

Some rules that apply to the definition of "Done":

  1. "Done" only applies to all user stories & sub-cases that also have children (in FogBugz)
  2. Only "Done" cases can be closed
  3. Only create Unit Test for items with a "Unit Test" sub-case.
  4. If the user stories has a "Unit Test" sub-case, then the unit test must be created prior to the actual implementation of the case.