Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Performance/Remove Unused Locals

I know what this means, I think, as I have found code where a variable is declared and never used, so I remove it. However, I see this one in FxCop all the time too:

Warning, Certainty 95, for "RemoveUnusedLocals"

{

Target : "SaveData():System.Boolean" (IntrospectionTargetMethodBase)

Id : "_Vb_t_i4_0" (String)

Location : "file:///C:/Projects/AM.NET/CDS%20Forms/General/UIBase.vb<1075>" (String)

Resolution : "UIBase.SaveData():Boolean declares a local, '_Vb_t_i4_0',

of type CustomDataSystems.AMNET.Forms.General.UIBase+FileMaintenanceModuleName,

which is never used or is only assigned to. Use this

local or remove it."

Help : "http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.312&&url=/Performance/RemoveUnusedLocals.html" (String)

Category : "Microsoft.Performance" (String)

CheckId : "CA1804" (String)

RuleFile : "Performance Rules" (String)

Info : "Remove locals that are not used or are only assigned

to in method implementations."

Created : "4/6/2005 4:25:13 PM" (DateTime)

LastSeen : "4/6/2005 4:25:13 PM" (DateTime)

Status : Active(MessageStatus)

Fix Category : NonBreaking(FixCategories)

}

 

What does "declares a local, '_Vb_t_i4_0'" mean anyway?

 

4 Comments

  • Looks like it might be a temporary variable created by the VB.NET compiler. Is it possible to post the method that generated that IL?



    Better yet, are you compiling in debug or release mode? I think doing a release build will optimize unused variables out.

  • I agree it's a temp variable, just did not know what was generatingit.



    Good call, analyzing a release build does not produce the fix. Thanks! I can ignore these on our Debug builds now.


  • That means you are using a Int32 variable in your method emmited by the compiler. I ignore this in most cases. Case statements cause this to happen when you use a field, such as:



    Public Class Foo

    Private _me As Int32 = 3



    Public Function Bar() As Boolean

    Select Case _me

    Case 1

    ' do something



    If you look at the IL code, you'll see that the compiler creates a local variable of type Int32 to hold the value of _me. It then assigns the value of _me to the local variable and then uses the local variable for the case statements instead of going and loading the value of the field to the stack for each comparison. Its actually optimized this way. I just ignore those because it is a compiler emitted variable, nothing you coded necessarily.

  • I just found out that this particular violation will be fixed in the next FxCop version from a guy on the team. This was a bug and the FxCop should not be catching compiler emitted locals, such as the one you described.

Comments have been disabled for this content.