Scope of variables in C#

Question

I got a question for you guys on C# code writing: I had a long debate with collegue of mine: He says that by declaring and initilizing all variables in the beginning of the function make code more readable and fast.

Please give me at least one sane reason that it could be right.

1. It's not readable as if you have a long function, you have to have huge declaration scope after intialization scope, so this is much easier to declare the variable you need where you need it, so you will see it in fron of you.

2. It's not absolutely faster, as you allocate unnecessary memory and pump the function stack.

This pseudo code example mine:

public void A(double dParam) 
{         
    if(... condition ... ) {
        double dAnotherParam;
        string sParam; 
        ...
        // use local scope vars here
     }   
}

Pseudo code example him:

public void A(double dParam) 
{
    double dAnotherParam;
    string sParam; 

    dAnotherPatam = 0; 
    sParam = null;     

    if(... condition ... ) {
        ...
    }                   
 }

Any ideas on topic?

Thank you in advance.

Answer 1

declare variables in the scope you intend to use them.

Answer 2

It's quite simple and straightforward. This rule is what I use in my code all day every day.

Declare variables at the lowest scope you can get away with.

If you're only using a variable inside of a method, declare in the method, no need to place it at the class level.

Edit: You seem to be asking about scope variables in methods specifically.

In that case think about it this way, if your usage of a variable depends on whether or not a condition is true, why declare it before you even pass the condition. You'd be wasting resources by doing so.

Answer 3

In terms of the code running faster with all the variables declared at the top of the routine, I would argue that the oppposite is the case, if there is any difference at all. I am no expert on this, but I assume that garbage collection will be more efficient by declaring variables at the lowest scope you can. That way cleanup can occur sooner.

Additionally, by putting variables close to the code that uses them, it improves readability IMO.

An analogy is that it is the difference between having margin notes (put right beside the text you are reading), vs. a wall of footnotes at the bottom of the page (you are not sure what footnote relates to what text without doing some cross-referencing yourself).

Answer 4

Performance doesn't matter because the compiler will take care of this. The compiler doesn't care whether you declare them at the top of the method or just before you use them.

However, having 20 declarations at the top instead of declaring the variable when you use it doesn't make the code more readable.

I would absolutely go for the first option.

Answer 5

Declaring variables at the top of a method is very old school and is a hang over from C. I was taught this exact same thing at University.

Now days we try to keep methods very small and lean with meaningful parameter and method names. It is much cleaner to declare and initialize a variable inside the scope in which it is going to be used. If there are many such areas of code with in a given method it may be an indication that you should refactor out to smaller easier to read methods.

The only time I would consider doing this is when you want to initialize something inside a try catch finally statement where you want to do something with the object with in the catch or finally block.

SomeObject someObject = null;

try
{
    someObject = GetSomeObject();
    return someObject.DoSomething();
}
finally
{
    if (someObject != null) someObject.DoSomethingElse();
}

Most of the time all you want want to do is clean up the object so a using statement is more than adequate but there are times when it is needed.

Answer 6

To add another point, you may not always want to initialise variables that are declared at class level. Sometimes you may want these things to be null and you actively test for that.

Also, you mention you have very long methods... methods should be functional, do a particular purpose and then return to the program flow. So long methods often can refactored into smaller manageable code.

Answer 7

It sounds like your colleague is an old C programmer. It used to be that you had to place all of your variables at the beginning of the scope, and people got used to doing it that way.

In C#, it's better to place them at the scope where they are needed. This has a few benefits, including:

• You reduce the risk of error from reusing a variable inappropriately, especially during long term maintenance
• You are keeping the variable constrained within that scope, which eases refactoring

The last point is, in my opinion, the most important. Good maintainability and testability rely on the abiltiy to keep your methods small - and keeping variables declared as they're used makes extracting a method much, much simpler. Not only do the tools become more effective, the resulting automatic refactorings tend to be simpler (as the variable isn't passed in by ref, etc).

---

As for your example code - I personally would do it differently than either of you. You're still declaring your variable at the beginning of the inner scope. I wouldn't declare them until they are actually used:

public void A(double dParam) 
{         
    if(... condition ... ) {
        double dAnotherParam = GetValueFromMethod();

        // use local scope vars here

        // Later, as needed:
        string sParam = dAnotherParam.ToString(); 
     }   
}

Declaring these at the top of the scope (even an inner scope), again, reduces the ability of automatic refactoring tools from successfully extracting methods as needed.

Answer 8

In my opinion, the declaration at the beginning of the function is way less readable than the declaration at the lowest scope possible. You should pay attention that your code is readable as this is much more important than this micro speed optimization.

Answer 9

Re: readability, you're quite right. And also consider that declaring variables at a higher scope loses any information about where they're relevant to. A user looking at it needs to read the entire method to see where a variable is used. Furthermore, there's more risk of mistakenly using the wrong variable.

Answer 10

1. It's not readable as if you have a long function, you have to have huge declaration scope after intialization scope

This just indicates that you need to refactor the code. In fact, it's good that forward declarations force you to think this stuff through.

It's not absolutely faster, as you allocate unnecessary memory and pump the function stack.

Ideally, you don't. If some branch of your code needs to allocate objects which are orthogonal to the rest of the function, it's better to offload this branch into a separate function.

This way you keep to the "declare where you use it" principle, too.

Answer 11

It's not readable as if you have a long function, you have to have huge declaration scope after intialization scope, so this is much easier to declare the variable you need where you need it, so you will see it in fron of you.

I am not understanding how that would be more readable either. It moves the declaration away from the section of code that intends to use it resulting in the loss of proximity clues.

It's not absolutely faster, as you allocate unnecessary memory and pump the function stack.

The argument that it is faster is also wrong. It does not matter where in the method a variable is declared it still takes the same amount of space on the stack. So there is not any fundamental differences in performance that I am aware of¹. However, you could make the argument that declarations with inline initializations would consume extra CPU cycles if the initialization is deemed to be unnecessary. For example, you might declare and initialize a variable inside an if block in which case the initialization occurs only if the execution dives into that block. Contrast that with what would happen if you did the declaration and initialization at the top of the method.

¹_{I suppose there could some weird consequences of method inlining or the like that could effect this, but I doubt it.}

Answer 12

A rule of thumb I have always followed is to populate variables as close to their declaration as possible, this means dont declare a variable on line 10 then give it an initial value on line 100.

Answer 13

This is a matter of style. My considerations:

1. If the code block is small, in the end it won't matter where you place the declaration. However, it's preferable to have declarations nearer use, mainly in large code blocks. First, this way you can make sure that the variable wasn't modified until that point in the block, and second, because you can check the type and initialization of the variable faster.

2. Besides, its faster to code by declaring variables near where you use them -- you don't have to scroll back to the beginning of the scope just to declared a forgotten variable and then move back.

3. This isn't faster or slower. Variables, no matter where declared in the scope, will have their allocation and initialization centered at the beginning of the scope. This can be checked by generating IL for the language.

For example, the code:

static void Main(string[] args)
{
    var a = 3;

    if (a > 1)
    {
        int b = 2;
        a += b;
    }

    var c = 10;
    Console.WriteLine(a + c);   
 }

Generates the following IL:

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       24 (0x18)
  .maxstack  2
  .locals init ([0] int32 a,     // Declare a
           [1] int32 b,          // Declare b
           [2] int32 c)          // Declare c
  IL_0000:  ldc.i4.3             
  IL_0001:  stloc.0              
  IL_0002:  ldloc.0              
  IL_0003:  ldc.i4.1             
  IL_0004:  ble.s      IL_000c
  IL_0006:  ldc.i4.2
  IL_0007:  stloc.1
  IL_0008:  ldloc.0
  IL_0009:  ldloc.1
  IL_000a:  add
  IL_000b:  stloc.0
  IL_000c:  ldc.i4.s   10
  IL_000e:  stloc.2
  IL_000f:  ldloc.0
  IL_0010:  ldloc.2
  IL_0011:  add
  IL_0012:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_0017:  ret
} // end of method Program::Main

One important thing to notice is that variables in internal scopes, such as the variable b, which was at the if scope, is declared at method scope by the compiler.

Hope it helps.

Answer 14

First, its not recommended to have a big functions. If u declare a variable in scope which u want to use is better because no extra initialization and smallest assembly jumps required so causes to faster running.

Answer 15

Your colleague's point is from old school programming. Not that it is bad, but this comes from assembly language.

At the beginning of an assembly code, you had to declare the DS register (Data Segment) which made some allocation on the stack in order to reserve some memory. Here is a code sample:

.MODEL SMALL

.DATA 
    myVariable1 DW "This is my first variable"
    myVariable2 DB "Second var"

.CODE 'code segment

:ProgramStart

    MOV AX,01h
    ...

:ProgramEnd

As the others have already said, in C programs, the variable declarations had to be in the beginning of a function. Just like you needed to write your functions definitions in the beginning of your C program, before the main() function, then writing their body after your main function, otherwise your function (or variable) was not recognized. So yes, this was faster because the variable address was already known by the generated inline code.

However, with the coming of OOP and event programming, we tend to stay as close to the event as possible. What I mean resumes itself being your point of view. Today's compilers parse the code for such variables throughout the code and make it a manageable CLR code. So this no longer make a difference, speaking of performance. In today's programming, we tend to make the code as easy to read and understand as possible. That said, this includes variable declarations.

Declaring a variable in the beginning of a function, and using it only 20 lines further is no use, plus it tends to make the program harder to understand. For example, you're analyzing a piece of code, then hop! a variable name appears, but no declaration around. Where this variable comes from, shall you ask? You will need to scroll up (or go to the definition) to find out what is this variable. Meanwhile, you may have lost your idea about the purpose of the routine you were actually reading and trying to understand. Make it three or more times, and your lost trying to understand the code.

It's better to have a lean and swift point of view of the purpose of the code. That is, don't declare any unecessary variable before it really is indispensable. Writing this way will avoid one always scrolling up and down while reading or writing the code of a program.

This is my two cents. I hope to be clear enough in what I have been trying to explain.

I hope this helps anyway!

Answer 16

Pascal was one of the later languages I learnt, where everything had to be declared up-front as per your buddie's example. Forgive us, earlier languages didn't allow variables with close scope à la .NET, so "old habits die hard".

Performance is no longer an issue, the cost in programming is manpower. Compilers have become cleverer than most of us, so the real issue is avoiding errors. (Forgive me for illustrating in VB, I simply make less typos.)

Compare:

Dim X as integer = 0
' 100 lines of drivel, where I'm forgetting about X
For X = 1 To 10
  If pornographic(X) then ' Pron integers, geek alert!
    Viagra(X)
  End if
Next
' 50 lines of drivel, X lurks with his raincoat

If X >= 10 Then ' Compiles. X=11, if you're damn lucky
  ' make a nasty mistake
End if

Don't laugh, it happens every day.

With:

' 100 lines of drivel, nothing lurid in sight
For X As Integer = 1 To 10
  If pornographic(X) then ' Pron integers, geek alert!
    Viagra(X)
  End if
Next
' 50 lines of drivel, X is no more

If X >= 10 Then ' *** FAILS AT COMPILE-TIME ***
  ' *** CAN'T *** make a nasty mistake
End if

Easy answer, right?

Maurice

P.S. I forgot to declare: Public Protected Viagra(clipno As Film) ...