string.Empty and ""

Yes

But I think that fxcop would recommend using "" (performence) since string.empty creates a new instance of string.

Avi.harush at 2007-9-9 >

There is already a rule (TestForEmptyStringsUsingStringLength, CA1820) that tests string comparisons.

See http://www.gotdotnet.com/team/fxcop/Docs/Rules/Performance/TestForEmptyStringsUsingStringLength.html for more details.

PeterRitchie at 2007-9-9 >

If our method body representation (as expressed in Method.Body) was as it should be, the most straightforward thing to do would be to override VisitAssignment and VisitMethodCall. The Source member of an assignment statement could be checked for a literal that devolves to "". You would do the same with MethodCall.Operands.

Unfortunately, this check will be complete for any methods which contains nesting of calls/arguments. In this case, all operands that follow the nesting will consist of a Pop instruction and there's no way, currently, to resolve these arguments to variables (without writing your own code to do so). The next version of FxCop will ship with an unnested IL representation, in which nested calls are assigned to temporary variables.

Until then, you might want to write a rule that simply examines all the IL instructions looking for OpCode.Ldstr. Cast the value of any located instruction to a string and then check its value against "". The IL for direct usage of "" should vary from usage of String.Empty, as the latter will result an ldsfld of the public const field String.Empty.

Note that there's a strong possibility of the Method.Instructions member going away entirely. If it does, however, it will be because we've resolved the blocking issues in Method.Body's representation. I think we'll have a preview of these bits within a couple of months.

MichaelFanning-MS at 2007-9-9 >