I also declare them at the bottom of the class declaration, but that’s another story.

1) Instance fields don’t get coloured differently from local variables in the average IDE.
2) Putting an underscore in front groups them together in class browsers.

It wouldn’t be hard to improve the tooling in these areas, of course…

@Wayne: a better naming for your CountIsValid() method would be to start with Is as in IsValidCount(), see also the Framework Design Guidelines or on MSDN Library.

Also like Davy mentions there are several reasons why you should not use complex properties and it is because it is possible that consumers of your API will use the property in a for-loop for example without caching the returned value of a property in a local variable first:

for (var i = 0; i < someClass.Count; i++)
{
Foo(someClass.Count);
}

Because you dont expect too much complexity in the getter for Count property. But when a developer sees that it is a method they tend to cache it in a variable first:

for (var i = 0; i < someClass.GetCount(); i++)
{
Foo(someClass.GetCount());
}

They will probabyl write this:

var count = someClass.GetCount();
for (var i = 0; i < count; i++)
{
Foo(count);
}

I think it has to do with psychology

public int Count
{
int count = 0;
get { return count; }
set { if (CountIsValid(value)) {count = value;} else {throw new InvalidArgumentException();} }
}

This would remove the need to most of the fields in most classes

Resharper(Ctrl+B) ==> requires an extra click to see information that could be there at all times. Not everyone installs R#. Navigating back is an extra step. Depending on where you navigated to, navigating back can prove problematic given VS behaviour.
VS(goto definition) ==> requires an extra click to see information that could be there at all times. Slow. Navigating back is an extra step. Depending on where you navigated to, navigating back can prove problematic given VS behaviour.
Reflector(click on the variable) ==> requires an extra click to see information that could be there at all times. Reflecter is way too late. This insight is needed when working with source, not when reverse engineering compiled assemblies.

+1 for _. All the benefit of “this.”, but with less typing. None of the overhead of going hunting for information interactively when it could just _be there_.

The naming thing doesn’t really matter, as long as you’re consistent.

+1 for the 2 general practices about using fields.

The only place I use warts is writing BDD specifications. Mostly because the spec runners tools “can” generate a friendly version of the specifications.

In the end, I don’t think it’s something worth thinking about all that much

Still, a visual indication is nice to have. So if you do not use Resharper, prefixing them with an underscore doesn’t seem at all that bad to me. Then again, why would one not use Resharper?

The reason I noticed was not down to some inbuilt software engineering smell detector; it was purely down to the fact that the unnecessary use of fields frequently made the code harder to follow. You have to jump around looking to see what the field is, who accesses it and so forth.

It should also be noted that NDepend’s LCOM metric will flag up classes that have fields accessed by a small proportion of its methods. This could be useful for identifying classes with this problem.

I think method structure & size are more important, just apply SRP in moderation along with obvious naming and you can’t go wrong

also try not to use ‘if’ statements