C# programming style question - Assignment of Null Before Real Assignment

Question

Is there a good reason (advantage) for programming this style

XmlDocument doc = null;
doc = xmlDocuments[3];

vs

XmlDocument doc = xmlDocuments[3];

I have seen it many times but to me it just seem overly verbose

Answer 1

I would go with

void Foo()
{
  XmlDocument doc;

  //Do other code here

  //Create doc
  doc = xmlDocuments[3];
}

As doc may not be being used till later on in the method. It makes more sense to create doc just before it is used. Easier to read (less scrolling).

Answer 2

I would use

XmlDocument doc = xmlDocuments[3];

Declare variables where they are used.

Answer 3

No - it's generally considered best practice to declare a variable as late as you can, preferably setting it at the point of declaration. The only time when I don't do that is when I have to set a variable conditionally, or it's set in a more restrictive scope:

String name;
using (TextReader reader = ...)
{
    // I can't declare name here, because otherwise it isn't
    // accessible afterwards
    name = reader.ReadToEnd();
}

Reasons for declaring at the point of first use where possible:

• It keeps the variable's type close to its use - no need to scroll back up in the method to find it.
• It keeps the scope as narrow as possible, which makes the use of the variable more obvious.

Answer 4

I'm always trying to declare and assign variables on the same row if possible, so in this case I would try to use the second option. Fewer lines of code, less declared variables to keep in mind when reading the code also. In the end I think it's all about the coding rules you and your team uses though. We've had coding rules which says to declare all local variables in the beginning of the method, so I've seen both programming styles.

Answer 5

I prefer to use this one:

XmlDocument doc = null;
//blah blah
doc = xmlDocuments[3];

I just want assign and use 'doc' when it is required..

If I want use it right after assignment I go for

 XmlDocument doc = xmlDocuments[3];

Answer 6

If the variable 'doc' is assigned right after it is declared then no, I don't see any reason why you would want to do that. In any case, it certainly is not my style.

Answer 7

The declaration and assignment should ideally be paired for code legibility. In fact ReSharper will pick up any exceptions to this and suggest that they be joined.

Answer 8

They are different styles, and neither of them is objectivily better than the other. It's just a matter of taste. You can either declare the variable first and then assign a value to it:

XmlDocument doc;
doc = xmlDocuments[3];

Or you can do both in the same statement:

XmlDocument doc = xmlDocuments[3];

However, this form:

XmlDocument doc = null;
doc = xmlDocuments[3];

To assign a null reference to the variable and then immediately replace it with a different reference, is totally pointless.

Answer 9

As the others has pointed out the first style can be useful if you need to declare the variable outside the scope of a loop, if or something else. But in most cases I think this style is a remnant from the old days of Visual Basic 6 (and earlier) where you always had to declare a variable before using in.

Old VB didn't support your second style and therefore the first style is still popular...

Answer 10

I like to think of variables as 'shared' or 'not shared' in that some variables need to be used in multiple locations in the class or method, and some you only need to use once. For the former, I declare them all at the top of the relevant block, the latter I declare just before I use them.

It all depends on where you need to use them.

Case 1:

Xyz xyz = new Xyz; // Declared at the top.
// Loads of unrelated code in-between...
xyz.abc();
// More unrelated code in-between...
xyz.def(stuff);

Case 2:

// Loads of unrelated code above...
Xyz xyz = new Xyz; // Declared in a 'block'.
xyz.abc();
xyz.def(stuff);
xyz.destroy();
// More unrelated code below...

Answer 11

I agree mostly with Jon (Not to mention that usually I have to agree with him :-).

you have options:

1.

//Do something...
XmlDocument doc = xmlDocuments[3];
//use doc
//Do something...

2.

//Do something...
XmlDocument doc = null;
doc = xmlDocuments[3];
//Use doc
//Do something...

3.

//Do something...
XmlDocument doc = null;
//...Do something with other variables etc...
doc = xmlDocuments[3];
//Do something...
//Use doc

4.

//Do something...
XmlDocument doc = null;
//...Do something with other variables etc...
doc = xmlDocuments[3];
//Use doc
//Do something...

5.

//Do something...
XmlDocument doc = null;
doc = xmlDocuments[3];
//Do something...
//Use doc

6.

//Do something...
XmlDocument doc = xmlDocuments[3];
//Do something...
//use doc

I hope you can see that option 1 makes good sense.

It is best to keep declaration, definition and initialization as "together" as possible. Option 1 is example of declaration, definition and initialization done together in one line. You could compress it further:

var doc = xmlDocuments[3];

Vocabulary (language independent):

• Declaration: Coder introduces new name to compiler.
• Type binding: Type inference, use super-type etc.
• Definition: Coder makes compiler to reserve space. (on stack etc. - note that external names do not need space)
• Initialization: Coder assigns value first time during definition. Compiler does initialization (to nulls, 0, false, default values etc.) in most cases if coder omits initialization.
• Usage: Obvious!
• Scope: Obvious!
• Accessibility, where applicable. : Obvious!
• Modifier: Instance level, class level, method level, constant, readonly etc.

I hope this helps.

Answer 12

Guess I have been bad for years as typically I setup ALL variables first

// Define object variables string connectionString = string.empty; bla.. bla..

// Get connectionString connectionString = Configuration.Bla["connectionString"]