Refactoring

Historical Debugger and Test Impact Analysis in Visual Studio Team System 2010

I was browsing some of the awaited-for Visual Studio 2010 and I found a video about two interesting features related to what we do everyday (and I do not mean coding ;))

The first feature is related to debugging “history”. Normally, when you find a bug while running your program, you insert multiple breakpoints on the statements you suspect might caused it, and repeat the scenario or restart the debug session.

With history debugging, you don’t need to do so, since the history debugger “logs” every event in your application, so you can “pause” running and inspect all the previous events and may be check if there were “swallowed” exceptions.

The second feature, is when you want to modify some “unit-tested” code either for bug fixing or refactoring, and you want to re-run the impacted tests. Normally it is hard to determine which tests are affected so you run all of them, but with Test Impact Analysis in VS 2010, you can get the impacted tests once you save your modifications, so you can either commit your changes or undo.

Here is the 19 minutes video showing these two features on Channel 9

Historical Debugger and Test Impact Analysis in Visual Studio Team System 2010

StyleCop for ReSharper has been released

StyleCop for ReSharper has been released last week as a plugin for ReSharper to bring StyleCop code styling issues to ReSharper real-time syntax highlighting, quick-fixes, and Code CleanUp.

Although I personally don’t like many of StyleCop rules, but like ReSharper rules, they can be turned off individually. The plugin performance can also be customized from within the ReSharper options window.

More about StyleCop:

Microsoft StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project. It is another static analysis tool by Microsoft like FxCop, but the later analyzes the compiled object code for design issues, not the source code.

More about ReSharper:

ReSharper™ is a Visual Studio add-in created by JetBrains (the creator of many software productivity tools like IntelliJ®IDEA the Java IDE, TeamCity™ the build integration server, and dotTrace™ Profiler)

I have been using ReSharper almost since I started using Visual Studio and it has always been a complement to it. Even when Visual Studio evolved from 2003 to 2005, and finally 2008, ReSharper has still much to add.

One of the features I like most in ReSharper is its ability to detect syntax and styling error while you type, refactor code quickly, suggest variable names based on classnames, highlight redundant code, make code more readible, find references and jump to it directly if only once.

There has been some talks that Visual Studio 2010 is actually 2008 + ReSharper because of a mistake they made when they posted some snapshots of Visual Studio 2010 with ReSharper menus and screens in it.

Microsoft on the other hand had been promoting one of ReSharper competitors and announced a cooperation with DevExpress to license a free version of CodeRush Express exculsively for C# developers working on Visual Studio.

kick it on DotNetKicks.com

//Comments about comments

Although they are usually enforced by coding standards, and I strongly agree, I believe code comments should be minimized for many reasons:

  • Except for XML comments of methods and classes, most comments are not affected by automatic refactoring tools
  • Most developers forget to update comments after updating code
  • Sometimes they mix with temporarily commented code
  • Every one adds one or more additional lines to the source code
  • They might make the code ugly
  • They implicitly admit that your code cannot express your ideas
  • They cannot be validated by type checking or unit testing
  • Most of the times, there are more better alternatives than comments

Yet I believe they are highly needed in these cases

  • Writing important messages to self or others
  • Writing code review comments
  • Writing //TODO tasks for self or others
  • Writing failed trials to avoid reusing them later while refactoring
  • Writing justification for code that might not appear logical at first look

And finally here are some cases when comments can be replaced by better alternatives

if (i >= 5) // number of orders
if (numOrders >= 5) // <-- better option: use meaningful var names

if (custType == 5) // credit customer
if (custType == CustomerTypes.Credit) // <-- better option: use enums

if (custCredit >= 30) // credit over 30%
if (OverCredit()) // <-- better option: use methods (or properties)

private bool OverCredit()
{
    return custCredit >= 30;
}

if (a == b)
{
    if (d == c)
    {
        // ... long lines of code ...
    } // if (d == c)
} // if (a == b)

// Most decent IDEs highlight matching braces when u select one of them
// Also long lines of codes should be avoided, use methods

// begin saving data
    // ... long lines of code ...
// end saving data

#region Saving data               // <-- better option: use regions
    // ... long lines of code ...
#endregion

SaveData()          // <—- another better option: extract as method

// Modified by modeeb @ Feb 6, 2009 02:32:12 PM
// better option: use a version control system that have "blame" or "annotate" functionality

Coding to the core

I remember in my first job, I have joined a project that was based on an infrastructure built by some other developers who had left the company.

During my first days of training, I was told “never to touch” that infrastructure, and it made me write a funny poem about that on our whiteboard.

I was always encouraged to find other workarounds rather than modifying the infrastructure. And when it was really needed, it has to be kept minimal, done under close supervision, treated with high suspection, and always thought of first as the source of every bug that might appear later.

And in the following years, I started to read about good software design, refactoring, so I was always leaning toward “butchering” old code, but I always depended on my own manual testing to verify that I didn’t break anything in my refactoring “rides”. Manual testing was good for about 90% of the times, but there were few cases that skipped me, and hence I got that look “we told you not to touch it!!”. I was much experienced then, but it didn’t give me the right to try something that was considered a “taboo” before.

I still remember how terrified was one of my junior colleagues when I proposed adding a method to a base class instead of adding it to all subclasses.

Today, one of my colleagues asked me about a problem, and after 5 or 10 minutes of discussion, we found out that one of the solutions is to add the new required functionality to the base class (may be it was not the best solution, but it was better than the one she implemented). And then I wondered why didn’t she thought of it in the first place, and as I expected, she didn’t want to “touch” the base class although it was the straight forward solution, and thought of workarounds. And I was happy I encouraged her not to fear the “core”.

My point is, why do we keep building barriers to improvements? development is an innovative process, and it is the duty of seniors to encourage juniors to learn and try. In addition, we have all the tools that help us in our mission; source control, refactoring helpers, clone detectors, code analysis, unit testing, and more. And believe me, the cost of maintaining a badly designed project, is much much higher than the cost of a bug that might skip from the core.

I have also to stress that refactoring with freedom has to be coupled with extensive Unit Testing and Code Coverage, but that might be the topic for anothe post.