[Rule Proposal] Do Not Initialize Unnecesarily

[Néstor Salceda]

Title: Do Not Initialize Unnecesarily

Description: A field is initialized to its default value and the same
initialization is repeated in the constructor.

References: (I haven't found it in the MSDN, but I think it should be
there)
http://dotnetcorner.weblog.com/2008/5/FxCop-Rules-Causes-and-Fixes-Part-2.html

Bad example:

class Foo {
int a = 0;

public Foo ()
{
a = 0;
}
}

Good example:

class Foo {
int a;

public Foo ()
{
}
}

Good example:

class Foo {
int a = 5;

public Foo ()
{
}
}

Bad example:

class Foo {
int a;

public Foo ()
{
a = 0;
}
}

And that's all.
Néstor.

[Sebastien Pouliot]

On Fri, 2008-08-15 at 23:20 +0200, Néstor Salceda wrote:
> Title: Do Not Initialize Unnecesarily
>
> Description: A field is initialized to its default value and the same
> initialization is repeated in the constructor.
>
> References: (I haven't found it in the MSDN, but I think it should be
> there)
> http://dotnetcorner.weblog.com/2008/5/FxCop-Rules-Causes-and-Fixes-Part-2.html

Here it is :)
http://msdn.microsoft.com/en-us/library/ms182274(VS.80).aspx

Note that it could be hard to test since (at least) csc8 and forward
will remove them when optimization (/o+) is enabled (and there are other
issues when it's not enabled). You should do a quick test with gmcs
before starting the rule.

Sebastien

[Marek Safar]

Hello,

>> Title: Do Not Initialize Unnecesarily
>>
>> Description: A field is initialized to its default value and the same
>> initialization is repeated in the constructor.
>>
>> References: (I haven't found it in the MSDN, but I think it should be
>> there)
>> http://dotnetcorner.weblog.com/2008/5/FxCop-Rules-Causes-and-Fixes-Part-2.html
>>
>
> Here it is :)
> http://msdn.microsoft.com/en-us/library/ms182274(VS.80).aspx
>
> Note that it could be hard to test since (at least) csc8 and forward
> will remove them when optimization (/o+) is enabled (and there are other
> issues when it's not enabled). You should do a quick test with gmcs
> before starting the rule.
>

That's correct, gmcs works in similar way removing even more than csc
but not all possible cases. The case which is neither optimized by gmcs
nor csc is this one.

class Foo {
int a;

public Foo ()
{
a = 0;
}
}

The main reason is that compiler does only simple optimizations therefore I think this case is worth implementing.

Marek

[Néstor Salceda]

Hey,

El sáb, 16-08-2008 a las 08:45 +0100, Marek Safar escribió:
> >
> > Note that it could be hard to test since (at least) csc8 and forward
> > will remove them when optimization (/o+) is enabled (and there are other
> > issues when it's not enabled). You should do a quick test with gmcs
> > before starting the rule.
> >
> That's correct, gmcs works in similar way removing even more than csc
> but not all possible cases. The case which is neither optimized by gmcs
> nor csc is this one.

Umm, thanks you very much for your feedback.

> class Foo {
> int a;
>
> public Foo ()
> {
> a = 0;
> }
> }
>
> The main reason is that compiler does only simple optimizations therefore I think this case is worth implementing.

Okey, I see.

I'm going to propose other rule then :)

Thanks for your feedback :)
Néstor.

[Sebastien Pouliot]

huh ? did I miss something ? because Marek comment (the way I read it)
was positive that the rule (even if some cases were not applicable) was
worth implementing.

or did you want to do a rule that has a bigger potential impact for
Mono ?

Sebastien

p.s. Marek, thanks for the feedback and additional information :)

[Néstor Salceda]

Hey,

El dom, 17-08-2008 a las 10:29 -0400, Sebastien Pouliot escribió:
> On Sat, 2008-08-16 at 21:20 +0200, Néstor Salceda wrote:

...

> > > The main reason is that compiler does only simple optimizations
> > therefore I think this case is worth implementing.
> >
> > Okey, I see.
> >
> > I'm going to propose other rule then :)
>
> huh ? did I miss something ? because Marek comment (the way I read it)
> was positive that the rule (even if some cases were not applicable) was
> worth implementing.

Argh! I think I misunderstood the e-mail :( I was a bit distracted when
I was reading the e-mail. I'm sorry :(

> or did you want to do a rule that has a bigger potential impact for
> Mono ?

Nop, I think this rule has a bigger potential than the other one.

Is not a problem, this will be my next rule :)

Thanks you guys!
Néstor.