Peter Ritchie's MVP Blog : Software Development

Evolving code over time

PeterRitchie — Tue, 31 Mar 2009 04:02:00 GMT

Given economics, time constraints, resource limitations, etc.; you can't write all the functionality for a given solution for a single release. Even if you weren't limited by these constraints, you're likely to get changing requirements as development progresses and everyone learns more about the software under development.

It's fairly easy to prioritize what is developed and what isn't. You simply develop only what you need (see YAGNI). But, how do you manage adding new functionality without causing undue grief? One way is to only make additive changes to the code. For example, let's say we have the method create CreateRequestPacket that creates a blob of bytes to send to a host over the wire:

public static byte[] CreateRequestPacket()
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = NO_OPTIONAL_DATA_FLAG;
    result[2] = (byte) (result.Length - 2);

    Random random = new Random();
    for(int i = 3; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

In iteration x it writes out a request making certain assumptions about what the request contains. But, in iteration y it needs to optionally include other data. A non additive way is to simply modify CreateRequestPacket to do what is needed:

public static byte[] CreateRequestPacket(bool useOptionalData)
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = OPTIONAL_DATA_FLAG;
    int index = 2;
    if(useOptionalData)
    {
        result[index] = GetOptionalData();
        ++index;
    }
    result[index] = (byte) (result.Length - index);

    Random random = new Random();
    for(int i = index + 1; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

Now all calls to CreateRequestPacket need to change before a build can occure and you might not be able to modify all the files that contain these calls. So it causes undue blocking and forces you to change a number of files before you can check the file that CreateRequestPacket is contained withing.

Another way of implementing this would be to implement an additive change. That is, add a method that does what is needed and change the previous implementation to call the new method. For example:

public static byte[] CreateRequestPacket(bool useOptionalData)
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = OPTIONAL_DATA_FLAG;
    int index = 2;
    if(useOptionalData)
    {
        result[index] = GetOptionalData();
        ++index;
    }
    result[index] = (byte) (result.Length - index);

    Random random = new Random();
    for(int i = index + 1; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

public static byte[] CreateRequestPacket()
{
    return CreateRequestPacket(false);
}

This allows you to check the file that contains CreateRequestPacket in right after passing unit testing and allows you to gradually change all calls to CreateRequestPacket as time permits.

DevTeach 2009 Vancouver

PeterRitchie — Thu, 26 Mar 2009 16:33:00 GMT

The schedule for DevTeach 2009 Vancouver has been announced (http://www.devteach.com/). There’s lots of great software development sessions from some of the leaders in our industry.

If you’re planning on improving yourself, this is the conference to go to. Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains.

If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price: http://www.devteach.com/Register.aspx

Developing with Source Code Control - Best Practices Part 2

PeterRitchie — Wed, 11 Mar 2009 14:36:00 GMT

[Edited 14-Mar-09: clarified generated code SCC practice]

This edition provides SCC vocabulary and some more practices that make development life easier.

Vocabulary
Trunk
The root of the project or database. Sometimes called mainline or baseline; depending on the SCC structure, this is where most of the development occurs.
Mainline
The root of the project or database. Sometimes called trunk or baseline; depending on the SCC structure, this is where most of the development occurs.
Baseline
The root of the project or database. Sometimes called mainline or trunk; depending on the SCC structure, this is where most of the development occurs.
Tag
A snapshot in time of the system or a project/subfolder in the system. Usually also associated with an annotation explaining the significance of that point of time. Also known as label.
Label
A snapshot in time of the system or a project/subfolder in the system. Usually also associated with an annotation explaining the significance of that point of time. Also known as tag.
Branch
A "copy" of subfolders and files that are controlled separately from the trunk with an intention to eventually merge back into the trunk.
Merge
Unifies two independant changes into one. Often the process of merging requires manual resolution of conflicts.
Merge Conflict
When two independant changes cannot be automatically merged.
Commit
Same as check in
Check in
When changes are written to the repository.
Head
The most recent version of code in the system.
Fork
For the most part, same as branch--depending on the SCC system. More fun to use than branch, "I forked the code".
Copy-modify-merge
Under this SCC model the SCC always merges changes back into the database (trunk or branch, depending on what you're editing). This model assumes a team model where there is the likely posibility of more than one person working on the same file at the same time. This model rarely precludes the ability to lock a file before modification if changes to the file cannot be merged). This is the preferred SCC model.
Lock-modify-unlock
Under this SCC model the SCC forces devs to lock files they wish to edit before modifying them. (with IDE integration this is often transparent).
ALM
Application lifecycle management.

Practices
Don't use Visual SourceSafe for your SCC system.
Believe me, I've been there and have the scars to prove it. Visual SourceSafe (VSS) has a unique process that isn't mirrored by many major contemporary SCC systems. VSS is a distributed file-based SCC system and as such is prone to data corruption--not really something that is acceptable in any sort of "Control" system. Branching is really difficult in VSS. If you're one person and you have your VSS database on the same computer; you're likely fine. Otherwise, do yourself a huge favour and consider another SCC system, like Subversion (it's free). VSS doesn't scale well; as time goes on and the database increases in size, developers are added to the project, VSS gets slower and slower.

Don't put generated code in SCC
SCC provides the ability to rollback to a state in the past that allows compilation of the solution. Code that is generated [edit start] as part of the/a build process [edit end] can be generated at any time; there's no need to put that code into SCC. With lock-modify-unlock SCC systems, generated code that is checked-in will be locked and cause errors during build unless you lock it on every build. This will cause conflicts in lock-modify-unlock systems in that you end up not being able to build while somone else is building (yes, you likely build serveral times a day).

Make sure unit tests pass before checking in.
This means *all* unit tests. If you check in a change that causes a unit test to fail, someone else won't know where to start to make that unit test pass. You're wasting your time and setting the project schedule back by not ensuring unit tests pass before checking in changes. If your team allows it, use some sort of continuous integration suite. This allows you to get feedback upon every check-in that tells you whether all the unit tests pass. If you have an SCC or ALM that supports it, enable guards that force the unit tests to pass before changes are allowed into SCC.

Work on one set of related changes at a time.
It's more efficient to work on one thing at a time. Switching back and forth from task to task means wasting time getting into a different frame of mind and sometimes a different configuration. This also causes issues with SCC in that you've now got modified files that you're not currently working on. The longer they're kept unmerged, the more likely there will be issues during merge (someone else made a changed that conflicts with yours, and if everyone else is checking in often, you're the one that has to deal with all the conflicts). The more things you're working on at once, the more likely that one set of changes becomes dependant on another and you simply can't check your files in until all the changes you're working on are complete. Work on one set of related changes at a time and check those changes in to avoid not merging your changes often.

Check-in often.
SCC provides developers the ability to keep a history of their changes. But, this only works if you check your changes into the SCC system. When you have something that compiles, check it in. The more often you check changes into the SCC system the less likely you'll get into a situation where you have to deal with merge conflicts. The more often you check changes into the SCC system the least complex the changes will be. If the changes are not complex and you do run into a merge conflict, the less work will be involved in resolving the conflict. Do your sanity (and the sanity of your team mates) a favour and check in often. See next practice.

Avoid leaving changes overnight.
Check in your working changes before you leave for the day. If it compiles and works (unit tests pass) there's likely no harm to checking in. Leaving work for an extended period of time means it's that much harder to get back into that mindset; if you check in and describe the check in, you now have a history of the day's changes with an annotation making it easier to get back in that mindset. But, since you've checked the files in, you may not need to get back into that mindset (if you didn't check in, you *must* get back in that mindset in order to check in).

Never destroy SCC content.
SCC offers the ability to get back to a project state at any time in the past. If you destroy content from the system, this incapacitates this ability. It goes against keeping any sort of history of a project to destroy content, so don't do it unless you intend never to make use of the history for that project (i.e. you're destroying and entire project and you never intend to work on it again or support it).

Don't Bypass Copy-modify-Merge
Eventually you'll be in a situation where you need to edit a file at the same time as another person. In this case you'll need to merge your changes. The copy-modify-merge model accepts this inevitable fact and makes merging a first-class citizen of your development process; not some nebulous process that occurs only occaisionally. With a properly designed system the need to merge should be minimized. I've seen teams instigate a policy that you must lock the file before you modify it. I've also seen teams configure a SCC provider to automatically lock a file when changes are made to it. This is the wrong thing to do on software development teams. It leads to one of two things: 1) people just stop working when they can't lock the file they need to edit; or 2) they end up forcing copy-modify-merge that isn't supported by the tools they're using, which often leads to human errors and errors in merging.

I hope to continue this series as time goes on, if you have suggested topics, please comment. I expect to keep pretty generic; but could get SCC-system-specific, if there's interest.

A Upcoming Pandemic of Domain Anaemia

PeterRitchie — Thu, 29 Jan 2009 17:10:00 GMT

There's a well-known anti-pattern called the anaemic domain model[1][2]. This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour).

It should be obvious that a domain model that isn't truly object oriented is a domain model with a problem. But, let's look at other reasons why the Anaemic Domain Model is an anti-pattern. Your Domain is the nexus, the essence, of your system.

An anaemic domain model is basically a reporting system. Each "Entity" becomes, essentially, a query. This is fine, reporting systems are necessary and prevalent. But, to shoe-horn a domain model on top of this leads away from good reporting patterns that could add value and increases complexity, needlessly. The designers spend most of their time trying to force entities on the system, without recognizing the basic reporting nature of the system. This usually leads to "reports" that have to pull in multiple domain "entities" to generate the report--rehydringing data into an entity (usually through some sort of ORM) with no value added. i.e. an ORM that will manage the child-parent relationship (and either pre-load or lazy-load aggregates) doesn't provide much value here.

The worst case scenario with an anaemic domain model is that there really is behaviour there; but it's not handled in the domain entities; it's handled in a different layer. This is a problem because this circumvents the whole point of a domain model and layering.

One indication of anaemia is that most of the domain classes simply contain attributes. Anyone familiar with patterns should recognize this as a Data Transfer Object, not a Domain Entity. There's nothing wrong with DTOs, they're very important in almost all systems with any sort of complexity; but they're not Domain Entities. Let's be truthful, there are systems with little or no behaviour in the domain; and that's not a bad thing. Systems like this likely don't need a Domain Model and may not need techniques like Domain Driven Design. The quicker people recognize that, the quicker they can be using a more appropriate architecture and design. In some extreme cases the anaemic-domain-entity-DTOs service other DTOs

Now, where am I going with this? Well, there's been a series of guidance out of Microsoft Patterns and Practice about some application "patterns".

First, let me describe what a pattern is. A pattern is a way of "documenting a solution to a design problem" [3]. First, for it to be a pattern, it needs to detail the problem and it's context, then provide a solution. The latest "patterns" from P&P do not detail the problem or a context. They're simply architectural descriptions.

Now the association between the Anaemic Domain Model and the latest P&P guidance. In 3 of the 5 recently publish "patterns" the following is detail is included: "A Domain Entity pattern is used to define business entities that contain data only." This is the very definition of an Anaemic Domain Model. Plus, in the RIA pattern the following, contradictory, detail is included: "Domain entities are responsible for implementing business rules. Entities from the domain model represent business objects that contain data and implement behavior [sic]. In other words, the business objects are responsible for implementing business operations and interacting with other business objects."

This is disconcerting because historically sample code and guidance from Microsoft is simply reused without thought. This leads to poorly designed and architected applications, and the .NET community as a whole is seen as one that produces poor-quality code and design. Without context about the problems these patterns try to solve, they will be misused—likely forced upon contexts and situations where they don’t fit, simply because “they’re from Microsoft”.

[1] MF Bliki- AnemicDomainModel

[2] Anemic Domain Model - Wikipedia, the free encyclopedia

[3] Design pattern (computer science) - Wikipedia, the free encyclopedia

Technorati Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model,Microsoft

del.icio.us Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model

It’s More Than Syntax

PeterRitchie — Thu, 29 Jan 2009 15:00:00 GMT

Writing good software is not just about adhering to a programming language's syntax. No programming language syntax enforces good design nor does it enforce good programming in all circumstances.

I've seen many systems that compiled perfectly fine; but they weren't good systems. Some exhibited reliability problems. Some exhibited maintainability problems. Some exhibited performance issues. Some exhibited resistance to change. All eventually failed at some point; either the system could not change at the required pace, or could never attain an acceptable reliability, etc.

What was wrong with these systems? The programmers didn't look beyond the syntax of the language. They didn't accept that programming was about correctly constructing software, not simply writing syntactically correct code. In almost all cases, the projects didn't have design experience to guide the programming. The lack of leadership meant that other factors like time-to-market completely dominated the quality of code written.

Now, I'm not saying that big-design-up-front makes for better software. Big-design-up-front may help with some of the problems of these systems; but it doesn't help with others and it introduces more problems.

Any good software system needs a certain amount of design, up front--you need to know what you're going to be working on both from a requirements point of view and an architectural point of view. The lowest common denominator is generally some architectural vision based upon established wisdom. With some systems, this doesn't even need to be complex. Just enough to guide everything the programmers do.

With any system, its goal is to fulfill the requirements of the stakeholders. Some requirements (often many) are known at the onset of the project; but some are elicited throughout the evolution of the system. I say system instead of project because a successful system generally consists of more than one project. A project could be as granular as a particular iteration, or may be as wide as a project release. In either case a system changes over time for as long as the system is in use. To ignore that is to doom the system to failure. Ignoring the fact that the system must change over the life of the system usually results in things like "requirements sign-off", lack of iterations, big-design-up-front, etc.

In any case, gauging the correctness of a system based on errors/warnings from the compiler is a mistake. The architecture of the system must utilize established patterns for it to be maintainable and for it to be able to evolve over time. The development of the system must employ unit testing to ensure the correctness of the system in light of its evolution. The system must be monitored over its evolution to ensure it's following the architectural design. If it's not following the architectural design, find out why; and re-evaluate the architecture if need be.

In short, good programmers know much more than simply the syntax of the language they're using.

Technorati Tags: software design architecture

House of Cards Design Anti-pattern

PeterRitchie — Tue, 27 Jan 2009 16:00:00 GMT

I've had this anti-pattern in my head for years. It's an observance of some projects and methodologies that I've witnessed over the years. I believe it's a form of Voodoo Programming, Programming by coincidence, and is often a side effect of Cargo Cult Programming.

Anti-Pattern Name
House of Cards Anti-pattern

Problem
A problem occurs when software is written that works in a specific observed scenario but no one knows why it works in that scenario. Observation of "working" is taken as enough evidence of completeness. It is very often not enough to observe something working in one scenario for the software to be considered "correct".

This is often a result of continual hacks in sole response to correcting bugs without consequence to design or maintainability. Repeated hacks (cards) are are placed on top of other hacks until something has the appearance of "working" then all development on it stops and no one wants to go near the code again for fear of breaking it.

At the very least, House of Cards design is fragile, hard to maintain, un-agile. Worst case it's is of low quality and prone to error and data lose.

This is a general sign of cowboy coding. I means there is no acceptable methodology, and no real management. There's little development direction, and likely no development leadership (at least none with any meaningful experience). Features are generally driven solely by an external source that communicates directly with developers.

Symptoms

When reviewing code or questioned about code, developers respond with comments like "don't touch it, it works", or "we don't want to change it because it works". There's a reluctance to change the code because no one really knows why it works. The code stagnates, new features are slow to be implemented, and there's a general un-assuredness about the code.

The code is generally procedural, although following object-oriented syntax.

Refactored Solution

Establish experienced development leadership. Establish a development methodology that separates the stakeholders from the developers.

Invoke Agile methodologies to manage the requirements of the project and begin Agile redesign of the code employing unit testing, refactoring, patterns, etc. Aggressively refactor the code adding unit tests to test for specific problems as they arise, until the code is robust and reliable. Mandate adherence to SOLID principles: classes adhere to Single Responsibility Principle, Open-Closed Principles, Liskov Substitution Principle, Interface Segregation Principle, and uses the Dependency Inversion Principle

Technorati Tags: design,anti-pattern,software development

Pass-through Constructors

PeterRitchie — Fri, 21 Nov 2008 18:09:00 GMT

Pass-through constructors is a term I use to describe parameterized constructors that have none of their own logic and simply pass parameters to the base class. For example:

    public class BaseClass
    {
        private String text;
        public BaseClass(String text)
        {
            this.text = text;
        }
    }
 
    public class DerivedClass : BaseClass
    {
        public DerivedClass(String text)
            : base(text)
        {
        }
    } 

Pontificating Virtual Parameterized Constructors in C#

PeterRitchie — Tue, 18 Nov 2008 17:55:00 GMT

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation. He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class. One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class. His suggestion was effectively to add the concept of virtual parameterized constructors to C#. I detail “parameterized constructors” because C# already effectively has virtual default constructors. In the following example the base constructor (Form()) is automatically called by the derivative:

    public class MyForm : Form
    {
        public MyForm()
        {
        }
    }

Virtual parameterized constructors are not new, and from a mere language standpoint this seems reasonable. Pragmatically though, I believe, this is another story. It seems logical to be able to simply inherit the parameterized constructors of the base class; but, there are so many times that this isn't the case or some generally accepted principles that would be contravened by a language addition like this.

Let's first look at the open/closed principle (OCP). The OCP suggests classes should be open for extension but closed for modification. Robert Martin suggests [1] properly designed class hierarchies that obey OCP implement an abstraction; i.e. derive from an abstract class or implement an interface. For example:

public interface IShape
{
    void Draw(Graphics graphics);
}
 
public class Rectangle : IShape
{
    //...
    public void Draw(Graphics graphics)
    {
        ///...
    }
}

Second, let's look at the "prefer composition over inheritance" principle. The effect of a language change like this on a design that prefers composition should be fairly obvious. Here's an example of this principle:

public interface IPolygon {
    void Draw(Graphics graphics);
}
public sealed class Polygon {
    private readonly Point[] points;
    public Polygon(Point[] points) {
        this.points = points;
    }
    public void Draw(Graphics graphics) {
        for(int i = 1; i < points.Length; i++) {
            graphics.DrawLine(Pens.Black, points[i-1], points);
        }
    }
}
 
public class Rectangle : IPolygon {
    private readonly Polygon polygon;
    public Rectangle(Point location, Size size) {
        Point[] points = new Point[5];
        points[4] = points[0] = location;
        points[1] = new Point(location.X + size.Width, location.Y);
        points[2] = new Point(location.X + size.Width, location.Y + size.Height);
        points[3] = new Point(location.X, location.Y + size.Height);
        polygon = new Polygon(points);
    }
    public void Draw(Graphics graphics) {
        polygon.Draw(graphics);
    }
}

Obviously there is no way to use virtual parameterized constructors here.

Clearly, designs that take into account OCP and prefer-composition-over-inheritance would not benefit from a "virtual parameterized constructor" language addition.

Finally, let's look at why a class might have many constructors causing such friction for derivatives. There's many reasons why a class might have many constructors. I believe all are indications of a poorly designed class. My first thought would be that many constructors is a result of a large class and that the large-class-code-smell should be an indication for redesign. A large class could be in an indication of a motherclass; but in either case this is likely a single responsibility principle (SRP) violation and the class is doing much more than it should and be redesigned. If the class isn't large but has many constructors, this was likely done not in response to how the class should/would be used but to cover every possible way of constructing the type. This would then be a YAGNI violation and the number of constructors should simply be pared down.

But, what about when you have to deal with poorly design hierarchies and don't have the ability to modify them? A valid point; but, simply for the lack of friction of writing pass-through constructors I don't think adding to the language to support poorly designed classes is a good for the language or its developers.

While an addition like virtual parameterized constructors seems benign, its limited actual usefulness makes the effort not worth the reward. Plus, it introduces greater abilities to create poorly designed types.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf

Developing with Source Code Control Best Practices Part 1

PeterRitchie — Sat, 18 Oct 2008 13:54:00 GMT

This post will detail some first principles about source code control (SCC) and provide what I consider the most basic of practices that every dev should follow.

What is SCC?
SCC provides developers the ability to keep a history of their changes. SCC allows developers the ability to group file changes together with an annotation. SCC allows developers the ability to get back to the state the project was in at any given point in time, arbitrary or specific (Beta 1, RTM, etc.). SCC provides development teams the ability to more easily work on the same files at the same time. SCC allows developers to see who did what, when, and usually why. SCC allows development on more than one branch of the code at a time. Depending on the SCC, SCC allows developers to link changes to tasks, work items, etc.

Basic practices
Never check in changes that cannot be built.
This is pretty self-explanatory. Referring back to what is SCC: "SCC allows developers the ability to get back to the state the project was in at any given point in time". This means anyone can get back to a state where the project won't build if you check in changes that cannot be built. This causes undue friction at points temporally distant from the changes--which means there lots of work (time) involved to find and implement a solution (e.g. is the state 5 seconds before better, is the state 5 seconds after better, etc? All things that need to be researched and tested before continuing--wasting time and resources).

Check in related changes atomically.
This builds on the first practice, if all related changes are checked in as a unit the likelihood of that check-in breaking the build is highly improbable. Atomically means all related changes are checked in at the same time. With most SCC systems this is extremely simple, and usually means selecting all the files you have edited (or all the subfolders you have modified folders in--or the one subfolder if you have unrelated changes, see part 2). This might mean avoiding SCC IDE integration if your changes span several solutions. If you can't check in changes atomically (really question this if you think you can't. If you honestly can't, I'd suggest changing SCC systems) order the check ins to avoid build problems. For example, if you added an enum to somefile.cs, then used that new enum in someotherfile.cs, check-in somefile.cs before checking-in someotherfile.cs. Checking in somefile.cs first will not put the source code in a state where it cannot be compiled. You're working on a team, anyone on the team can get the state of the project at any time, like between non-atomic file check ins. This means they get code that doesn't compile and they won't know why or how to fix it--blocking them from doing their work and wasting time and impacting the project schedule.

Make use of shelving.
If what you've coded needs to be given to someone else to get the source code to build properly, don't check it in in order to give it to that other person. On cases like this, if your SCC has shelving or shelvsets, shelve the changes and inform the other person of the shelvset instead of checking in. Let them check in the working changes as an atomic unit. If shelving isn’t an option (consider or petition for an SCC system that does, then), send them the files for them to check in after modifications. See next practice.

Get all current code and build before checking in.
Someone may have made changes between when you got the code you working on and when you want to check in. If you don't get the latest code (and potentially merge it with yours), what you check-in may leave the controlled code in a state where it cannot be built. Get all the current code to make sure you have what will be the state of the code when you check in and that it builds first. If your build process is long, this may require several tries. You should address build times if this is a common problem. Communicate to the rest of the team that you need to check in changes and that they hold off on checking in related components if necessary.

Software Process and Reduction of Quality

PeterRitchie — Thu, 04 Sep 2008 14:51:00 GMT

Ken Schwaber had a conversation with Scott Hanselman about the concept of "done". He said that software developers have a habit of culling down all the generally accepted practices of software development except the writing of code. He says that, when pushed, software developers reduce quality in an effort to produce a software product by a certain time. This leads to a huge debt that must eventually be paid.

These generally accepted practices include things like unit testing, refactoring, design, documentation, etc. In the case of producing an API or and SDK, I believe these practices includes community involvement. When a team developing an SDK, API, or IDE "goes dark", they're not doing their job properly--they're ignoring the fundamental reason for their work: the customer. This is a huge problem in our industry because software developers are effectively trained that schedules only include writing code and meetings.

I agree with Ken and would say that part of an Agile process includes a significant amount of time to communicate with customers need be scheduled.

Even if not professing to using an Agile methodology, if unit tests, integration tests, refactoring, and research don't take up a significant amount of the software development schedule or there's no scheduling of a significant amount of time to communicate with customers; the team is inept. In this day and age, I would hazard to say its downright felonious and fraudulent.

Becoming a Visual Studio Jedi Part 1

PeterRitchie — Tue, 02 Sep 2008 18:49:00 GMT

Becoming a Visual Studio 2008 (and often Visual Studio 2005) Jedi

In much the same grain as James' Resharper Jedi posts, I'm beginning a series of posts on becoming a Visual Studio Jedi. It involves getting the most out of Visual Studio off-the-shelf, doing things as quickly as possible and with as little friction as possible. I think it's useful for all users; but especially useful for those who are in situations where they can't install refactoring tools like Refactor Pro! or Resharper.

First, familiarize yourself with Sara's Visual Studio Tips blog; then subscribe to her blog.

I'll attempt to provide detail at a less granular level than Sara's blog (i.e. using a series of commands to perform a specific task); but I may overlap here and there

Take advantage of Auto-Hide
Like Jimmy Bogard and Jeffery Palermo, I have my Visual Studio UI very lean. 99% of the time, I'm working in code. The Solution Explorer (SE), Properties, Output, etc are auto-hide panes. When I need to use them I hover the mouse over the tab to make them visible, do what I need to do with them, then get back to the code. The Code Editor is the only window that isn't auto-hide or floating.

Navigate find results via keyboard
Whenever anything is displayed in a find results window, you can iterate each item in the list via a keystroke. The default C# keyboard map had F8 and Shift+F8 as the shortcuts for next and previous.

For example:

Press Ctrl+Shift+F to bring up the Find in Files form.
Enter "TODO\:.*refactor" in the "Find what" text box.
Ensure Match case, Match whole word are unchecked.
Ensure Use is checked and has Regular expressions selected.
Press Alt+F to search.

A Find Results window is displayed that shows the results of the search.

F8 goes to the first result.
Pressing F8 again goes to the next.
Pressing Shift+F8 goes to the previous result.

F8 and Shift+F8 work for most lists like Find Results 1, Find Results 2, Error List, Output:Build, etc.

File name extensions when adding classes
Do you find your self selecting text in the file name when you use the Add Class wizard? Or, do you always type ".cs" at the end of your file name? You may be happy to know you don't have to do that. Simply invoke the Add Class wizard and type the name of the class. The wizard adds the missing .cs for you. For example:
Press Alt+P, C
Enter "MyNewClass"
Press Enter
A file MyNewClass.cs is added to your project and it contains class named "MyNewClass".

Consider a Custom toolbar

There's generally only handful of toolbar buttons that you might need, especially if you're a keyboard user like me. There's some things that simply don't have a default keyboard mapping. Another good reason for having a custom toolbar item with only the buttons you use is if you often change the size of your Visual Studio window. The default layout has two or more toolbars (depending on the edition and any add-ins you have installed). You can carefully position those toolbars so they may take up one or two lines; but when you then shrink the size of your window the get wrapped and they won't restore if you expand the size of your window. Having a single toolbar means this wrapping of toolbars can never happen.

Export Settings

Once you get your UI the way you want it, you can actually save the layout.

Click on Tools\Import and Export Settings.
Select Export selected environment settings.

This is really handy if you get into low-resource situations (like the application you're developing or its framework uses up too many GDI handles and Visual Studio can't allocate a handle to display a toolbar or a frame. When this happens Visual Studio actually turns off those GUI elements; when you close and restart those panes/frames are no longer displayed by default.)

Trials and Tribulations of DataGridView, Column Selections, and Sorting

PeterRitchie — Tue, 26 Aug 2008 20:06:00 GMT

I had to implement some custom sorting in a DataGridView recently. Essentially, the stakeholders wanted full column selection (like Excel) while still having the ability to sort the data based on a particular column.

This particular DataGridView is data-bound. DataGridView offers the Sort(DataGridViewColumn, ListSortDirection) method to perform this. Nice and easy I thought: I’ll set the SelectionMode to DataGridViewSelectionMode.ColumnHeaderSelect and simply call Sort with the selected column.

Well, much to my chagrin this had the side effect of making that column look selected all the time. No matter where else I clicked, that recently sorted column looked selected (SelectedColumns had a count of zero). And to add insult to injury, when I control-clicked that column (thinking it was selected) to unselected it, it caused a NullReferenceException deep in the framework.

Suffice it to say, this makes it very difficult to sort by columns in DataGridView without using the built-in sort-column-when-header-is-clicked mode.

What I’m now attempting to do is to unselect the column before sorting it. This, in itself, is not trivial either; there’s no public method to select or deselect a column in the DataGridView. I’ve had to create a new DataGridView derivative and call the protected method SetSelectedColumnCore. A few hoops…

I’ve logged a couple of issues on Microsoft Connect about these problems. The first is about ctrl-clicking the column and getting an exception: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 The second is about the visual state of the column remaining “selected”: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 Attached to this post you will find the project referenced by the two Connect issues.

[Update: I've currently only tried this with a .NET 2.0 project in Visual Studio 2008 SP1; if you find this problem occurs in Visual 2008 RTM, please comment.]

[Update: I overlooked the DataGridViewColumn.Select property, so there's no need to derive from DataGridView]

The winds of change are blowing

PeterRitchie — Wed, 20 Aug 2008 15:14:26 GMT

The essence of ALT.NET, or at least the essence that people made use of, was that it was a venue for improving one's skills. There has always been an undercurrent of other agendas there; but they never really took root.

The problem with the ALT.NET moniker was it isolates it from most of the industry--it was an island of .NET practitioners. This basically flicked its thumb at the other communities--other communities that propagated some of the guidance that ALT.NET was trying to proliferate.

In the very spirit of continuous improvement it seems that ALT.NET is attempting to evolve and the ALT.NET conferences may continue (at least for a period of time, until the next kaikaku) as Kaizen conference.

Kaizen is a much more appropriate name for what people use and get out of the ALT.NET conferences. I just hope this change doesn't cause division, distrust and dissent (for lack of a better word).

I've said from the beginning that "ALT.NET" had some flaws as a name. I hope Kaizen will continue to give the same people the ability to improve, while embracing more.

Extra Features: One of the Lean 7 Wastes of Software

PeterRitchie — Mon, 18 Aug 2008 15:11:00 GMT

Derik Whittaker recently blogged about how writing unused code is one of the Lean 7 Wastes of Software. Mary Poppendieck calls this "Extra Features" and has a one-to-one association to overproduction in manufacturing.

In Manufacturing it has different caveats: if you overproduce something you have to have somewhere to store it until its sold. What do you do when you don't have the space to store it? If you have the space, it's not too much of an issue; you just tuck it away; but you still need people to move it, manage the space, manage the responsibilities around moving/storage, etc. etc.

With Lean Software, there is still technically a storage issue (VCS, disk space, etc.). The real issue with extra features is that no one is using them. In the best case this means you're consuming expensive resources that aren't directly increasing revenue. Worst case you're also impacting the usability (and thus the sell-ability) of the software. If the extra features are something that the vendor hopes to be used in the future; then you've increased the time between implementation and fixing bugs. Unit testing aside, when customers log bugs against the software regarding something implement 6 months ago, you've increased the cost of fixing the bug exponentially as time goes on. This is the philosophy behind TDD, that unit tests find bugs as soon as possible (~build time, depending you your setup).

From an Agile standpoint, extra features mean you're giving the user something they didn't want. This means you're not listening to your customer and don't have a relationship built on communication. In Agile, it's a tenet to build prototype code based ideas you've inferred from communication with the customer. This isn't extra features, this is the feedback process. It's fine to propose a feature to the user in the form of a prototype; but if they don't want it, it doesn't go into the release.

Extra features is technical debt that you'll have to pay for eventually.

Law of Reversibility of Attributes

PeterRitchie — Wed, 13 Aug 2008 21:55:00 GMT

I've come up with a simple law called Law of Reversability of Attributes. It’s based on the physics law of a similar name. Basically what the law means is that the inverse of a transformation should result in a return to the original state.

The Law of Reversibility of Attributes is defined as:

For a given state of an object; when a attribute’s value is changed, the inverse of that value, when applied to that attribute, will result in the object returning to its original state.

I say “attribute” rather than “property” to encompass methods that imply setting of attributes. So, for example

            myObject.BooleanValue = !myObject.BooleanValue;

            myObject.BooleanValue = !myObject.BooleanValue;

and

            myObject.SetBooleanValue(!myObject.GetBooleanValue());

            myObject.SetBooleanValue(!myObject.BooleanValue());

means myObject will be in the same state after the second line of code than it was before the first line of code.

[UPDATE: interestingly, after I wrote this post--which was delay-published--Bill Wagner wrote a great article on a very similar topic in Visual Studio Magazine]

DataGridViewColumn.Frozen

PeterRitchie — Mon, 11 Aug 2008 22:34:00 GMT

DataGridViewColumn.Frozen is documented as "When a column is frozen, all the columns to its left (or to its right in right-to-left languages) are frozen as well."

Which is nice until you think of the consequences. The consequences being that freezing a column and all columns to the left is performed with a single assignment of true to the Frozen property of that column; but to unfreeze is not the opposite (a assignment of false to the Frozen property of that column). No, you must unfreeze each of those columns to the left. This can be done by manually unfreezing each column, or by unfreezing column 0.

This means that column.Frozen = false is not the opposite of column.Frozen = true—resulting in unbalanced reversible side-effects.

Neither of the techniques to “unfreeze” the column that was frozen is intuitive; but unfortunately this interface is not "intention revealing". You’re not just setting the Frozen property of a column, you’re setting the frozen property of that column and all the columns to the left.

Greg Young recently commented (I don’t remember where) about writing classes without any properties. This approach would have helped here. What Greg is alluding to is to recognize behaviour rather than shape. Freezing the current column and all columns to the left is a behaviour, not an attribute; and it should be modeled as a method rather than a property.

At any rate, if you have a DataGridView on your form, you may be interested in using these methods instead:

        private void FreezeAtColumn(int value)

            dataGridView.Columns[value].Frozen = true;

        private void UnfreezeColumns()

            dataGridView.Columns[0].Frozen = false;

ITSWITCH #1: Answer

PeterRitchie — Mon, 28 Jul 2008 19:00:00 GMT

Last post I detailed some code that may or may not have something wrong in it. If you thought InitializeOne and IntializeTwo are semantically identical (e.g. they differ only by performance), you'd be wrong.

If you simply ran the code, you'd be able to guess where the problem is. To understand what's causing the problem. Let's look at how C# effectively implements the two loops.

InitializeOne is essentially equivalent to

        private class PrivateDelegateHelper

            public String Value { get; set; }

            public void Method()

                TestClass.ProcessText(Value);

        public void InitializeThree(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            MethodInvoker cachedAnonymousDelegate = null;

            PrivateDelegateHelper privateDelegateHelper = new PrivateDelegateHelper();

            String[] copyOfStrings = strings;

            for(int i = 0; i < copyOfStrings.Length; ++i)

                privateDelegateHelper.Value = copyOfStrings;

                if (cachedAnonymousDelegate == null)

                    cachedAnonymousDelegate = new MethodInvoker(privateDelegateHelper.Method);

                delegates.Add(cachedAnonymousDelegate);

Now it's obvious, right?

For those you don't want to read all the code, the problem is that only one PrivateDelegateHelper object is instantiated and its value property is set in each iteration of the loop. Because the delegates aren't run until sometime after the loop, they're all run with the last value of the string array as their argument.

The technical term for what we've implemented here is a closure. If you're using Resharper 4.x, you would have noticed a warning "Access to modified closure":

...which is attempting to tell you that the closure (the delegate and cached bound variables) has changed (in this case one of the bound variables has changed between the creation of a closure and another and out expected output is effected).

By the way, you can get the same thing with C# 3+ with lambdas (i.e. you can also write closures with lambdas):

        public void InitializeOne(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            for (int i = 0; i < strings.Length; ++i)

                String value = strings;

                delegates.Add(() => ProcessText(value));

        public void InitializeTwo(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            foreach(String value in strings)

                delegates.Add(() => ProcessText(value));

ITSWITCH: #1

PeterRitchie — Fri, 25 Jul 2008 18:58:00 GMT

Is There Something Wrong In This Code Here

UPDATE: as several readers pointed out there was compile error in the code what was being displayed. The line "String value = string" was showing up as "String value = string". I'm not sure why; but throwing some spaces between the i and the square brackets seems to have solved it.

In the following class, is there something wrong with either InitializeOne or InitializeTwo (hint, it has nothing to do with compile errors and I'm ignoring performance differences)?

    public class TestClass

        private List<MethodInvoker> delegates;

        private static void ProcessText(String text)

            Trace.WriteLine(text);

        public void Run()

            foreach(MethodInvoker invoker in delegates)

                invoker();

        public void InitializeOne(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            for (int i = 0; i < strings.Length; ++i)

                String value = strings[ i ];

                delegates.Add(delegate { ProcessText(value); });

        public void InitializeTwo(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            foreach(String value in strings)

                delegates.Add(delegate { ProcessText(value); });

Answer on Monday.

Working with Resharper's External Annotation XML Files

PeterRitchie — Mon, 21 Jul 2008 20:32:00 GMT

Resharper 4.0 has external annotation XML files that you can create to give Resharper more information about your code. For example, you can tell Resharper that a particular method does not accept a null argument. For example, the following method does not accept a null argument:

using System;

namespace Utility

    public static class Text

        public static int GetLength(String text)

            if (text == null) throw new ArgumentNullException("text");

            return text.Length;

An external annotation file can be created to inform Resharper of this fact and have it warn you when possible null values are passed as an argument:

            String text = null;

            Utility.Text.GetLength(text);

First, you need to create a directory within the Resharper ExternalAnnotations directory. This ExternalAnnotations directory is usually in the form of "%SystemDrive%\Program Files\JetBrains\ReSharper\vBuild#\Bin\ExternalAnnotations" for example "C:\Program Files\JetBrains\ReSharper\v4.0.816.4\Bin\ExternalAnnotations".

The directory we need to create is the same name as our assembly (without the extension). In our case this would be "C:\Program Files\JetBrains\ReSharper\v4.0.816.4\Bin\ExternalAnnotations\Utility".

Next, we need to create an XML file to contain the information required by Resharper. The name of this file is the same as the directory name, plus ".xml". So, the full file name would be "C:\Program Files\JetBrains\ReSharper\v4.0.816.4\Bin\ExternalAnnotations\Utility\Utility.xml". This file essentially has an assembly element with child member elements that provide meta-data about methods and arguments. In our case we want to tell Resharper that the Utility.Text.GetLength(String) method does not accept null values for the argument named "text". To do this we populate the file with the following XML:

<?xml version="1.0" encoding="utf-8" ?>

<assembly name="Utility">

    <member name="M:Utility.Text.GetLength(System.String)">

        <parameter name="text">

            <attribute ctor="M:JetBrains.Annotations.NotNullAttribute.#ctor" />

        </parameter>

    </member>

</assembly>

After restarting Visual Studio, Resharper will now warn that "text", when passed to GetLength, in the following code, has a "Possible 'null' assignment to entity marked with "NotNull" attribute".

            String text = null;

            Utility.Text.GetLength(text);

I've tried this with the GA build and with both Visual Studio 2005 (SP1) and Visual Studio 2008.

For more information about the annotation options, search for AssertionConditionType in the Resharper help and browse around "%SystemDrive%\Program Files\JetBrains\ReSharper\vBuild#\Bin\ExternalAnnotations" for examples.

Drag-copying in Visual Studio Solution Explorer.

PeterRitchie — Fri, 18 Jul 2008 16:46:00 GMT

NOTE: I've tried this in Visual Studio 2008 (VS2k8), I'm assuming the same thing happens in Visual Studio 2005 (VS2k5).

In the process of refactoring, it's *very* common for me to rename a type. This is most easily done by renaming the file in the Solution Explorer (SE)--which renames the file, the type, and and any uses of the type in the entire solution.

Occasionally, I need to create a new type based on another. Copying an abstract type in order to implement the abstract type is often handy--I just fill in the abstract members (and delete "abstract") in the copied type after renaming it.

Drag-copy in the SE seems like it would take care of a couple of steps at once for me: make a copy and rename it. Unfortunately it doesn't do that. It makes a copy of the file (as "Copy of typename.xx") but doesn't rename any types in the class that match the file name.

This might seem somewhat trivial... I can simply rename the file name then refactor rename the type in the file so that the type and all it's constructors are renamed in one fell swoop. Alas, this simply opens a can of worms that can completely confound a newcomer and annoy an expert.

That simple, intuitive method of renaming a copy of a file then the type within the file actually renames *all* types of that name. Since we've just made a copy of the type, that means it's always going rename types in two files. The side-effect of drag-copy in SE means you *must* manually rename the type in the file you just copied. You can do this with search-replace; but that's friction I don't want and really makes SE drag-copy unusable.

I've logged a bug about it on Connect; but the olde "by design" card was played...