Performance

I didn't believe that the LINQ method could be faster, and I would never trust a profiler to give an accurate result (for numerous reasons), so I ran a benchmark with BenchmarkDotNet, and got the opposite result from tinstaafl. (Code in a gist)

Here are the results. Linq is as tinstaafl's, StringBuilder is as Joe C's, Char2 is as OP's second method, Char1a and Char1b are variations of what I would have suggested off-hand. On this machine (old i7), under .NET Core 2.1, in a dedicated benchmark, the OP's code was significantly faster than the Linq and StringBuilder methods. (Results may be very different under .NET Framework)

                Method |            TestString |         Mean |      Error |    StdDev |

---------------------- |---------------------- |-------------:|-----------:|----------:|

           ReverseLinq |                       |    81.472 ns |  0.1537 ns | 0.1284 ns |

         ReverseChar1a |                       |     7.946 ns |  0.1156 ns | 0.1081 ns |

         ReverseChar1b |                       |     7.518 ns |  0.0177 ns | 0.0157 ns |

          ReverseChar2 |                       |     7.507 ns |  0.0232 ns | 0.0206 ns |

 ReverseStringBuilders |                       |    12.894 ns |  0.1740 ns | 0.1542 ns |

           ReverseLinq |  It's (...)ow it [39] |   671.946 ns |  1.9982 ns | 1.8691 ns |

         ReverseChar1a |  It's (...)ow it [39] |    61.711 ns |  0.0774 ns | 0.0604 ns |

         ReverseChar1b |  It's (...)ow it [39] |    61.952 ns |  0.2241 ns | 0.1986 ns |

          ReverseChar2 |  It's (...)ow it [39] |    48.417 ns |  0.0877 ns | 0.0732 ns |

 ReverseStringBuilders |  It's (...)ow it [39] |   203.733 ns |  0.7540 ns | 0.6684 ns |

           ReverseLinq |               Magpies |   235.176 ns |  0.5324 ns | 0.4446 ns |

         ReverseChar1a |               Magpies |    23.412 ns |  0.0979 ns | 0.0916 ns |

         ReverseChar1b |               Magpies |    24.032 ns |  0.0582 ns | 0.0544 ns |

          ReverseChar2 |               Magpies |    22.401 ns |  0.1193 ns | 0.0996 ns |

 ReverseStringBuilders |               Magpies |    44.056 ns |  0.1313 ns | 0.1097 ns |

           ReverseLinq | ifhia(...) oiha [432] | 4,102.307 ns | 10.4197 ns | 9.2368 ns |

         ReverseChar1a | ifhia(...) oiha [432] |   454.764 ns |  1.0899 ns | 1.0195 ns |

         ReverseChar1b | ifhia(...) oiha [432] |   453.764 ns |  2.3080 ns | 2.0460 ns |

          ReverseChar2 | ifhia(...) oiha [432] |   400.077 ns |  1.0022 ns | 0.7824 ns |

 ReverseStringBuilders | ifhia(...) oiha [432] | 1,630.961 ns |  6.1210 ns | 5.4261 ns |

Note: never used BenchmarkDotNet before... hopefully I've not misused/misunderstood it in any way (please comment if I have), and hopefully it is good at it's job.

Commentary

Performance is not everything. The linq method is the most compact, and the hardest to get wrong, which is very good. However, if performance is important, than you need to profile the method as realistically as possible. The results above may not generalise. However, I'd be very surprised if the StringBuilder and Linq methods out-performed any of the char-array based methods ever, because they just incur a fair amount of overhead (i.e. probably a dynamic array, and probably a second copy in the LINQ case (not to mention the general enumeration overhead)).

Personally, I have no issue with your second piece of code. It may not be the most obvious implementation ever, but it doesn't take long to work out, and it's not a method whose job is going to change any time soon, so I'd worry much more about its API than its internals. That said, the API is a problem, as Adriano Repetti has mentioned: the behaviour of this method is going to create problems as soon as you start trying to reverse non-trivial Unicode. Simply, 'reverses a string' is a deficient contract.

Clarity of Approaches

With the first approach, I look at it and I can tell straight away that you are reversing a string. With the second approach, I need to study it for a minute or two to work out what you're doing.

Unnecessary Code

In the first approach, the check for an empty string is not necessary. In this case, your logic will not even enter the for loop, resulting in an empty string being returned anyway.

Performance

As you may know, strings are immutable objects in .Net. It is good practice to use a StringBuilder to create strings in this way, like so:

var reversedString = new StringBuilder(input.Length);

for (int i = input.Length - 1; i >= 0; i--)

{

    reversedString.Append(input[i]);

}

return reversedString.ToString();

I like the char approach, since it allocates the memory all at once and only makes one string. However using the LINQ extension method(return new string(input.Reverse().ToArray());) seems to do the same job in a fraction of the time according the .net profiler.

I would recommend neither of the approaches. Strings in .NET are a rather unfortunate data structure, they consist of UTF-16 units. This unfortunately exposes the peculiarities of the UTF-16 encoding to the programmer, which will in particular cause problems if your string contains characters from the Unicode astral planes (code points U+10000 and up). These are expressed as pairs of two surrogates, which when reversed will be invalid. There are also issues with combining diacritics: simply reversing the order of code points may result in a combining diacritic being associated with a different letter, or even no letter at all.

Since reversing a sequence of UTF-16 units is not a meaningful operation for textual data, the approach I would take is to use the built-in functionality to slice strings by text elements. This can be done using the System.Globalization.StringInfo class:

public static string Reverse(string source)

{

    var info = new StringInfo(source);

    var sb = new StringBuilder(source.Length);

    for (var i = info.LengthInTextElements; i-- > 0;)

    {

        sb.Append(info.SubstringByTextElements(i, 1));

    }



    return sb.ToString();

}

As noted in the comments, Unicode also supports control structures like bidirectional overrides and interlinear annotations that would end up with their delimiters in the wrong order after this routine. This would require further parsing of the output to switch the start and end characters for these control structures (in particular, the bidirectional characters can represent nested levels of LTR and RTL ordering).

Edit 23.01.19: another thing to note is that some scripts have specific rules about the characters depending on where they are in the word. For example the Greek lowercase letter sigma has a different shape if it is at the end of the word, and is encoded with a different code point in each scenario (U+03C3 GREEK SMALL LETTER SIGMA vs U+03C2 GREEK SMALL LETTER FINAL SIGMA). This will not be taken into account by the above routine, e.g. if you reverse the word "στάσις" you will end up with "ςισάτσ" not "σισάτς". If you require the reversal to take this kind of thing into account you are up for a very large challenge!

Moral of the story: Unicode is hard. This is not Unicode's fault: it is a consequence of the fact that text is hard.