exceptionz

Thoughts on Technology, Methodology and Programming.

Archive for the ‘Refactoring’ Category

Resharper 3.0 Member Re-Ordering Settings

Posted by Marcus Wyatt on 10 June 2007

In ReSharper 3.0 you now have the ability to specify how the Reformat action (Shortcut: Ctrl+Alt+F) should order the members within your code file.

image

The re-ordering feature is very nice if you want to adhere to a coding standard. e.g. Castle Project Coding Standards. Below is a breakdown of how ReSharper 3.0 would structure your code if you use the Re-order settings file:

  1. Every section is sorted by Access i.e. public, protected, internal, private
  2. Sections from top to bottom:
    1. Delegates
    2. Enums
    3. Constants
    4. Static & Readonly Fields
    5. Fields
    6. Constructors (Static then Instance)
    7. Destructors
    8. Instance Indexers (Sorted by Abstract, Virtual, Override)
    9. Instance Properties (Sorted by Abstract, Virtual, Override)
    10. Instance Methods (Sorted by Abstract, Virtual, Override)
    11. Event Handling Methods
    12. Events Declarations
    13. Operators
    14. Interface Implementations
    15. Class Indexers (Sorted by Abstract, Virtual, Override)
    16. Class Properties (Sorted by Abstract, Virtual, Override)
    17. Class Methods (Sorted by Abstract, Virtual, Override)
    18. All other members
    19. Nested Types

I thought the ReSharper 3.0 & Castle community might find the re-order settings file I created helpful. 

To add the settings you should open the Type Member Layout section of the ReSharper 3.0 beta options screen:

image

And then Copy the following XML into the Custom Patterns box:

<?xml version="1.0" encoding="utf-8" ?>
<Patterns xmlns="urn:shemas-jetbrains-com:member-reordering-patterns">

  <!--Do not reorder COM interfaces-->
  <Pattern>
    <Match>
      <And Weight="100">
        <Kind Is="interface"/>
        <HasAttribute CLRName="System.Runtime.InteropServices.InterfaceTypeAttribute"/>
      </And>
    </Match>
  </Pattern>

  <!--Special formatting of NUnit test fixture-->
  <Pattern RemoveAllRegions="true">
    <Match>
      <And Weight="100">
        <Kind Is="class"/>
        <HasAttribute CLRName="NUnit.Framework.TestFixtureAttribute" Inherit="true"/>
      </And>
    </Match>

    <!--Setup/Teardow-->
    <Entry>
      <Match>
        <And>
          <Kind Is="method"/>
          <Or>
            <HasAttribute CLRName="NUnit.Framework.SetUpAttribute" Inherit="true"/>
            <HasAttribute CLRName="NUnit.Framework.TearDownAttribute" Inherit="true"/>
            <HasAttribute CLRName="NUnit.Framework.FixtureSetUpAttribute" Inherit="true"/>
            <HasAttribute CLRName="NUnit.Framework.FixtureTearDownAttribute" Inherit="true"/>
          </Or>
        </And>
      </Match>
      <Group Region="Setup/Teardown"/>
    </Entry>

    <!--All other members-->
    <Entry/>

    <!--Test methods-->
    <Entry>
      <Match>
        <And Weight="100">
          <Kind Is="method"/>
          <HasAttribute CLRName="NUnit.Framework.TestAttribute" Inherit="false"/>
        </And>
      </Match>
      <Sort>
        <Name/>
      </Sort>
    </Entry>
  </Pattern>

  <!--Default pattern-->
  <Pattern RemoveAllRegions="true">

    <!--delegate-->
    <Entry>
      <Match>
        <And Weight="100">
          <Access Is="public"/>
          <Kind Is="delegate"/>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Delegates"/>
    </Entry>

    <!--enums-->
    <Entry>
      <Match>
        <Kind Is="enum"/>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Enums"/>
    </Entry>

    <!--constants-->
    <Entry>
      <Match>
        <Kind Is="constant"/>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Constants"/>
    </Entry>

    <!--static and readonly fields-->
    <Entry>
      <Match>
        <And>
          <Kind Is="field"/>
          <Or>
            <Static/>
            <Readonly/>
          </Or>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Readonly &amp; Static Fields"/>
    </Entry>

    <!--fields-->
    <Entry>
      <Match>
        <Kind Is="field"/>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Fields"/>
    </Entry>

    <!--Constructors. Place static one first-->
    <Entry>
      <Match>
        <Kind Is="constructor"/>
      </Match>
      <Sort>
        <Static/>
        <Access Order="public protected internal private" />
      </Sort>
      <Group Region="C'tors"/>
    </Entry>

    <!--Destructors. Place static one first-->
    <Entry>
      <Match>
        <Kind Is="destructor"/>
      </Match>
      <Sort>
        <Static/>
        <Access Order="public protected internal private" />
      </Sort>
      <Group Region="Destructors"/>
    </Entry>

    <!--Instance indexers-->
    <Entry>
      <Match>
        <And>
          <Kind Is="indexer"/>
          <Not>
            <Static/>
          </Not>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Instance Indexers"/>
    </Entry>

    <!--instance properties-->
    <Entry>
      <Match>
        <And>
          <Kind Is="property"/>
          <Not>
            <Static/>
          </Not>
          <Not>
            <Kind Is="indexer"/>
          </Not>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Instance Properties"/>
    </Entry>

    <!--Methods-->
    <Entry>
      <Match>
        <And>
          <Kind Is="method"/>
          <Not>
            <Static/>
          </Not>
          <Not>
            <HandlesEvent />
          </Not>
          <Not>
            <Kind Is="destructor"/>
          </Not>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Instance Methods"/>
    </Entry>

    <!--Event Handling-->
    <Entry>
      <Match>
        <HandlesEvent />
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Event Handling"/>
    </Entry>

    <!-- event -->
    <Entry>
      <Match>
        <Kind Is="event"/>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Event Declarations"/>
    </Entry>

    <!-- operator -->
    <Entry>
      <Match>
        <Kind Is="operator"/>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Name/>
      </Sort>
      <Group Region="Operators"/>
    </Entry>

    <!--interface implementations-->
    <Entry>
      <Match>
        <And Weight="100">
          <Kind Is="member"/>
          <ImplementsInterface/>
        </And>
      </Match>
      <Sort>
        <ImplementsInterface Immediate="true"/>
      </Sort>
      <Group>
        <ImplementsInterface Immediate="true" Region="${ImplementsInterface} Members"/>
      </Group>
    </Entry>

    <!--Class indexers-->
    <Entry>
      <Match>
        <And>
          <Kind Is="indexer"/>
          <Static/>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Class Indexers"/>
    </Entry>

    <!--Class properties-->
    <Entry>
      <Match>
        <And>
          <Kind Is="property"/>
          <Static/>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Class Properties"/>
    </Entry>

    <!--Class Methods-->
    <Entry>
      <Match>
        <And>
          <Kind Is="method"/>
          <Static/>
        </And>
      </Match>
      <Sort>
        <Access Order="public protected internal private" />
        <Abstract/>
        <Virtual/>
        <Override/>
        <Name/>
      </Sort>
      <Group Region="Class Methods"/>
    </Entry>

    <!--all other members-->
    <Entry/>

    <!--nested types-->
    <Entry>
      <Match>
        <Kind Is="type"/>
      </Match>
      <Sort>
        <Name/>
      </Sort>
      <Group>
        <Name Region="Nested type: ${Name}"/>
      </Group>
    </Entry>
  </Pattern>

</Patterns>

Enjoy!

del.icio.us Tags: , ,

Posted in Development, Refactoring, Software | 8 Comments »

JetBrains releases personal licence for Resharper

Posted by Marcus Wyatt on 6 February 2007

I just found this in my aggregated feeds. Great job JetBrains! I wish more companies would look into personal license scheme’s. Why? Well, I’m a independent contractor, thus I don’t have the income to justify spending uber dollars on getting an MSDN subscription or buy some of the very expensive tools I like. But I think if more companies looked at personal license schemes, then more freelance people would be able to afford their tools.

Another point I’d like to make, is how subscriptions like MSDN is composed. I would like to have the following Microsoft applications in some personal subscription scheme:

  • Visual Studio 2005 Team Suite
  • SQL Server 2005 Developer
  • Windows Vista Ultimate
  • Team Foundation Server
  • Office 2007

This is because I mainly use these applications in my day to day work. Thus for me it is important to keep up to date with the latest developments in these products.

Anyways, back to Resharper and JetBrains. They have the Personal License at $149.00 USD. Which is quite affordable for a very helpful tool. And to be honest, I am lost if I don’t have Resharper installed in Visual Studio. It is an absolutely necessity to have alongside Visual Studio…

Currently listening to: Paul Oakenfold – Essential Mix Live From Amnesia Ibiza 08-08-2004

tags: , , ,

Posted in Development, Refactoring, Software | Leave a Comment »

Refactoring – Going Generic

Posted by Marcus Wyatt on 18 July 2006

This post on the JetBrains.NET Tools blog descibes a nice way to refactor your array declarations to generic lists.

So, now that people are migrating from .NET 1.1 to 2.0, it would be great to somehow convert legacy interfaces from arrays to collections. For this, ReSharper comes in extremely handy. We ourselves used the following procedure when developing ReSharper 2.0 and we think it can be useful to you, too.

The post will give you a good introduction to a few of the really cool features of ReSharper.

Technorati Tags: ,

Posted in Refactoring, Software | 1 Comment »

Extreme Programming in Practice

Posted by Marcus Wyatt on 14 April 2006

Jefferey Palermo has the following posts about how Extreme Programming helped his team to successfully deliver their software system to their client. He highlights not only the good that he experienced, but also speaks about the bad and ugly:

I’d recommend these posts. The posts are really informative!

 

tags: , , , , ,

Posted in Agile, Refactoring, TDD, XP | 1 Comment »

Code Metrics, Code smells and Refactoring in Practice

Posted by Marcus Wyatt on 27 February 2006

In this article I describe how our team uses metrics to identify code smells and apply refactorings to correct these code smells. This example is real simple but it shows exactly how some of the eXtreme programming practices are helping our team to maintain our code. 

 

Our team uses eXtreme programming practices to manage development on a mission critical system for a large retail chain. We have not adopted all the practices, but use the majority of the practices.

Here is a list of the practices we use:

Every morning at the standup meeting the team lead will report on the nightly integration build.

This report includes the following metrics:

  • Unit tests passed, failed, ignored
  • Fit test passed, failed, ignored, exceptions
  • Test Coverage (Should be more than 80%)
  • Cyclomatic complexity (Should be less than 10)
  • Code Instructions (Should be less than a 100)
  • FxCop rule validations

Each day metrics are compared to the previous day and overall the project manager tracks these metrics to get an overall feel for the health of the project.

You can find the rest of the article here.

 

tags: , , , , , , ,

Currently listening to: 19 Vegas Soul-Junk Funk – Winamp *** 46. DANNY TENAGLIA – 19 Vegas Soul-Junk Funk

Posted in Development, Refactoring, TDD, XP | Leave a Comment »

Visual Studio 2005 Unit Testing Code Snippets

Posted by Marcus Wyatt on 24 February 2006

In this article I describe how our team uses metrics to identify code smells and apply refactorings to correct these code smells. This example is real simple but it shows exactly how some of the eXtreme programming practices are helping our team to maintain our code. 

Source Code Metrics

Our team uses eXtreme programming practices to manage development on a mission critical system for a large retail chain. We have not adopted all the practices, but use the majority of the practices.

Here is a list of the practices we use:

Every morning at the standup meeting the team lead will report on the nightly integration build.

This report includes the following metrics:

  • Unit tests passed, failed, ignored
  • Fit test passed, failed, ignored, exceptions
  • Test Coverage (Should be more than 80%)
  • Cyclomatic complexity (Should be less than 10)
  • Code Instructions (Should be less than a 100)
  • FxCop rule validations

Each day metrics are compared to the previous day and overall the project manager tracks these metrics to get an overall feel for the health of the project.

You can find the rest of the article here.

tags: , , , , , , , ,

Currently listening to: 1 – Winamp *** 53. Darren Emerson – Uruguay disc 1

Posted in Development, Refactoring, TDD, XP | Leave a Comment »

Use a refactoring checklist to pay down Technical Debt as you work

Posted by Marcus Wyatt on 13 August 2005

Jeremy D. Miller on the use a refactoring checklist to pay down Technical Debt as you work.

If you’ve never heard the term “Technical Debt,” check out Martin Fowler’s definition and Ward Cunningham’s Wiki on the subject.

The triumvirite TDD coding cycle of “Red, Green, Refactor” is plastered all over the web and endlessly repeated by all us TDD zombies. If you’re going to drink at the agile Koolaid fountain, don’t stop with just “Red Bar, Green Bar.” You’ve got to do the third part and Refactor as you work to keep the code clean.

  • Can you easily add more code to the solution tomorrow?
  • Is your code becoming difficult to read and understand?
  • Are you spending too much time with your debugger?
  • Is there a class or namespace you avoid changing out of fear?

You will slow down if you let problems accumulate. If you’re using evolutionary or incremental design you probably don’t know exactly where you’re going with your design. You are purposely delaying design decisions until you have more information and knowledge about the design needs. Keeping the code clean and each class cohesive with low coupling will maximize your ability to change later. Constant vigilence and an adherence to good coding practice can extend the lifecycle of a system by reducing the risk and cost of change.

Use aggressive refactoring to keep the technical debt from building up. Integrate refactoring into your normal working rhythm, don’t let it just build up into day long tasks. Here’s the good news though — a lot of refactoring work is quick and easy, especially if you’ll invest some time in learning the automatic refactorings in tools like ReSharper.

Find the whole post and comments here.

tags: , , ,

Currently listening to: mp *** 470. umek – expire ep (b2)

Posted in Development, Refactoring, TDD | 1 Comment »

Code Smell: CallSuper

Posted by Marcus Wyatt on 12 August 2005

CallSuper is a minor smell (or anti-pattern if you like) that crops up from time to time in OO frameworks. Its symptoms are pretty easy to spot. You are inheriting from a super-class in order to plug into some framework. The documentation says something like “to do your own thing, just subclass the process method. However it’s important to remember to start your method with a call to the super-class”.

An example might be something like this.

public class EventHandler {
   public void handle (BankingEvent e){ 
      housekeeping(e); 
   } 
}
public class TransferEventHandler extends EventHandler {
   public void handle(BankingEvent e) { 
      super.handle(e); 
      initiateTransfer(e); 
   }
}

Whenever you have to remember to do something every time, that’s a sign of a bad API. Instead the API should remember the housekeeping call for you. The usual way to do this is to make the handle method a Template Method, like this. 

public class EventHandler {
   public void handle (BankingEvent e) {
      housekeeping(e);
      doHandle(e);
   }
}
 
protected void doHandle(BankingEvent e) {
 
}
 
public class TransferEventHandler extends EventHandler {
   protected void doHandle(BankingEvent e) {
      initiateTransfer(e);
   }   
}

Here the super-class defines the public method and provides a separate method (often referred to as a hook method) for the subclass to override. The subclass writer now doesn’t have to worry his ugly head about calls to super. Furthermore the super-class writer is free to add calls after the subclass method if she wishes.

You can read Martin Fowler’s whole post here.

tags: , ,

Currently listening to: a, Part II – Winamp *** 2. Ayla – Ayla, Part II

Posted in OO, Refactoring | Leave a Comment »

Refactoring: Improving the Design of Existing Code by Martin Fowler

Posted by Marcus Wyatt on 22 May 2005

I love this book and it has a proud place on my desk at arms length.

A chapter outline:

  • Chapter 1: Refactoring, a First Example (C#)
  • Chapter 2: Principles of Refactoring
  • Chapter 3: Bad Smells in Code
  • Chapter 4: Building Tests
  • Chapter 5: Toward a Catalog of Refactorings
  • Chapter 6: Composing Methods
  • Chapter 7: Moving Features Between Objects
  • Chapter 8: Organizing Data
  • Chapter 9: Simplifying Conditional Expressions
  • Chapter 10: Making Method Calls Simpler
  • Chapter 11: Dealing with Generalization
  • Chapter 12: Big Refactorings
  • Chapter 13: Refactoring, Reuse, and Reality
  • Chapter 14: Refactoring Tools
  • Chapter 15: Putting It All Together

Every OO developer should have a copy of this great book.

tags: , ,

Currently listening to: - Winamp *** 349. u2 – lemon

Posted in Refactoring | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.