Clever - Maybe because your solution was the obvious one and this has fewer lines of code and leverages already available methods?
Best practice? Eh, maybe not, if I were using large data sets this obviously isnt ideal, but for small values of n like this challenge, it doesn't make a lick of difference.
If I wanted something more efficient I would have used a different approach, but it's a kata, not a time sensitive app.
sort mutates source.
So to avoid side effects, it must be copied before use.
If the kata wanted a CPU efficient solution it would have run very large data sets as part of the final tests.
Clever - Maybe because your solution was the obvious one and this has fewer lines of code and leverages already available methods?
Best practice? Eh, maybe not, if I were using large data sets this obviously isnt ideal, but for small values of n like this challenge, it doesn't make a lick of difference.
If I wanted something more efficient I would have used a different approach, but it's a kata, not a time sensitive app.
I don't see how this could be considered "Best Practice" or "Clever".
It needs
O(n*logn)in time to do something that could be done inO(n)Good to use "strings.Repeat"