It is redundant, but I would stay consistent. If you are always initializing fields, keep it that way regardless of the type. Also, as you pointed out in a comment, being required to think about default values for certain types is distracting, so another reason to initialize first.
Personally, I like this since you're saying to the world "I specifically want this to be 0". This reduces confusion when working in a team.
If you find it more readable that way, that's fine. I don't think it'll affect the JITted code - and even if it does, the performance hit will be absolutely tiny.
If ReSharper is annoying you when it comes to this warning, just configure it not to treat it as a problem. I don't have ReSharper on this machine, but I think it's fairly easy to find the relevant options - let me know if you can't and I'll look for it when I'm on the right machine.
I would say it's bad practice not to explicitly define the field. An uninitialized field should not be assumed to be the default value, it should be assumed as "null". In this case, you want it to explicitly be 0, and you should therefore declare it to be 0.
Resharper is a very strict coding style, and you shouldn't blindly listen to it, especially if it damages the readability of your code.
Furthermore, if someone were to need to port this to a different language (where perhaps the default value is undefined, rather than "0") then it would cause uninitialized variable compiler errors or, even worse, run-time errors.
If it like Java at all (on a cell phone... Hard to look up) then explicitly initializing it means you cannot mark the field as final (might be const in C#) which makes it harder to properly make an immutible class.
The general answer is like others have stated, if it makes more sense to you and your team then reset the Reshaper setting to a hint. The C# will initialize all values to their default value (0 for numbers, null for reference types) which is equivalent to the .NET 2.0 default operator:
int i = default(int);
EDIT: You wouldn't use the above in your code. It is equivalent to 'i = 0', however it is much less readable. I only used it to illustrate the point about the unnassigned variables are initialized with their default value.
When I see unneeded initialization I begin to wonder a little bit whether the person writing the code really understood .NET...and what other problems might be lurking in this code.
I guess it's a matter of taste, but as I've said elsewhere, I don't like redundancy.
Leaving off initializer for a field could either mean that the coder knew it would be initialized to default values, or that he knew it would not be initialized and didn't care, or else he didn't think about it and his code just happens to work. The latter two would be, shall we say, "educational opportunitites".
On the other hand, initializing a field to its default value says to me that the coder doesn't understand the platform, or doesn't trust it.
What about cases where the default value is never used? Cases where the field is initialized from all constructors, or where the field is always set before being read? In those cases, setting to the default value is not an indication of intent - only an indication of following a rule that makes no sense.
'And if you know .NET, there's really not much "thinking" about the default value. – Dan Mar 17 '09 at 11:53'
To Dan,
Do you really begin to wonder if someone understands .NET if they have to explicitly declare? I actually begin to wonder about people who questions other peoples coding ethic especially it is commonly a good practice and had no detriment in the final product. I explicitly declare everything because that is the way I code, that's the way I like to see it and, when I sell my code (not very often but I do), that is the way the customer likes to see it. I do understand .NET. Explicitly declaring is not a 'problem lurking in code'.