In the following examples:
- the first seems more verbose but less wasteful of resources
- the second is less verbose but more wasteful of resources (redefines string each loop)
Which is better coding practice?
First example:
using System;
using System.Collections.Generic;
namespace TestForeach23434
{
class Program
{
static void Main(string[] args)
{
List<string> names = new List<string> { "one", "two", "two", "three", "four", "four" };
string test1 = "";
string test2 = "";
string test3 = "";
foreach (var name in names)
{
test1 = name + "1";
test2 = name + "2";
test3 = name + "3";
Console.WriteLine("{0}, {1}, {2}", test1, test2, test3);
}
Console.ReadLine();
}
}
}
Second example:
using System;
using System.Collections.Generic;
namespace TestForeach23434
{
class Program
{
static void Main(string[] args)
{
List<string> names = new List<string> { "one", "two", "two", "three", "four", "four" };
foreach (var name in names)
{
string test1 = name + "1";
string test2 = name + "2";
string test3 = name + "3";
Console.WriteLine("{0}, {1}, {2}", test1, test2, test3);
}
Console.ReadLine();
}
}
}
Those are both wasteful and verbose.
.
This is my favourite part of Linq which I guess it fits here:
I generally declare variables as close to their use as scoping allows, which in this case would be your second example. Resharper tends to encourage this style as well.
Follow a simple rule while declaring variables
Declare it when you need it for the first time
I've found that 'hoisting' declarations out of loops is typically a better long-term strategy for maintenance. The compiler will usually sort things out acceptably for performance.
Depending on language and compiler it may or may not be the same. For C# I expect the resulting code to be very similar.
My own philosophy on this is simple:
Optimize for ease of understanding.
Anything else is premature optimization! The biggest bottleneck in most development is time and attention of the developer. If you absolutely must squeeze out every last CPU cycle then by all means do so, but unless you have a compelling business need to do or are writing a critical component (common library, operating system kernel, etc) you are better off waiting until you can benchmark the finished program. At that time optimizing a few of the most costly routines is justified, before then it's almost certainly a waste of time.