 It's dangerous to code alone! Take this.

The Three Lenses

The following is one possible solution to this challenge.

int[] input = new int[] { 1, 9, 2, 8, 3, 7, 4, 6, 5 };

foreach (int number in ProceduralCode(input))
Console.Write(\$"{number} ");
Console.WriteLine();

foreach (int number in KeywordSyntax(input))
Console.Write(\$"{number} ");
Console.WriteLine();

foreach (int number in MethodCallSyntax(input))
Console.Write(\$"{number} ");
Console.WriteLine();

IEnumerable<int> ProceduralCode(int[] input)
{
List<int> filtered = new List<int>();

// Filter to only even numbers.
foreach (int number in input)
if (number % 2 == 0)

// Sorting the results.
int[] results = filtered.ToArray();
Array.Sort(results);

// Doubling everything.
for (int index = 0; index < results.Length; index++)
results[index] *= 2;

return results;
}

IEnumerable<int> KeywordSyntax(int[] input)
{
return from n in input
where n % 2 == 0
orderby n
select n * 2;
}

IEnumerable<int> MethodCallSyntax(int[] input)
{
return input
.Where(n => n % 2 == 0)
.OrderBy(n => n)
.Select(n => n * 2);
}

// Answer this question: Compare the size and understandability of these three approaches. Do any stand out as being particularly good or particularly bad?
//
//    The procedural code is definitely the longest and ugliest. Query expressions using keywords and method calls are both far shorter,
//    and if you understand delegates, far easier to understand. The keyword approach is perhaps the fewest characters here, with a tiny
//    advantage over the method call syntax, since you don't have to keep reintroducing the variable `n`. In my opinion, it is a negligible
//    benefit when it comes to actual understandability.
//
// Answer this question: Of the three approaches, which is your personal favorite, and why?
//
//    The query expressions both have a clear advantage over the procedural code. It is hard to pick between the two of them, but
//    definitely not the procedural code because of its length and it is harder to understand. If forced to choose, I'd probably
//    give a slight advantage to method call syntax, for no reason other than it's the approach I more often do because there are
//    more options available with method calls than with the keywords. (None of those advantages show up with this code though.)