Is not to create it
The lack of clear criteria for beauty "in appearance" usually leads to a correction in the direction of a "beautiful" complex code. Separate classes of replayers, native work with Char (which is unknown how it works on surrogate pairs), string builders, that’s all.
The lack of clear criteria for beauty "in speed" usually leads to "optimization" where it is not needed. You have a code for fixing "randomly typed characters in another language." Let's test it on strings with a length of 100,000 characters per 1000 iterations! Users write War and Peace every day, forgetting to switch the layout. And then they are upset that the code works as much as 6 milliseconds to correct this error. 0.5 ms for them - a tangible difference!
In your case:
- There are no strict (really reasonable, not "it would be cool") requirements for performance, no clear beauty requirements (imho, the code that solves this problem in more than 10 lines is terrible!)
- There are no memory requirements (your version, for example, spends
(размер строки)^2 bytes, and the garbage will be thrown away immediately, and then gen 0 will not go away).
The only remaining requirement is readability . She is maintainability.
Readability can be measured by standard metrics. The same studio can count Code Metrics.
So, provided that the eng / ru is declared as static, the Maintainability Index benefits from two options:
for (int i = 0; i < eng.Length; ++i) query = query.Replace(eng[i], ru[i]);
and a little more new, but the same in essence
// считаем один раз, оптимизация! static (char, char)[] dictionary = eng.Zip(ru, (a, b) => (a, b)).ToArray(); //.... foreach (var (e, r) in dictionary) query = query.Replace(e, r);
It is with inline:
foreach (var (e, r) in eng.Zip(ru, (a, b) => (a, b))) query = query.Replace(e, r);
In the limits you set, all other options are self-indulgence.
tab[113]=223), and replace it by it. Of course, for the "correct" index is equal to the value, i.e.tab[223]=223. Well, or the same, but in the form of a string literal, where the position is equal to the code of the wrong character, the character is correct - but it will be slower. - Akina