I could have forgone the "join("")" to make the code shorter and slightly more transparent.

That thread was actually really interesting, thnak you. I will adapt my views, but probably not my coding practice (as this was pounded into my head, it's gonna take some time to unlearn).

But honestly thank you for giving me a chance to learn something ,this was really cool.

While one should refrain from creating a spaghetti control flow, the "single entry, single return" guideline originates from times and reasons long forgotten and it has not much of applicaiton today: https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from . People stick to it because they like to repeat seemingly authoritative stuff without exactly understanding it. Excessive sticking to Single Return Rule (no more room for Single Entry Rule in modern languages) is usually a cargo cult programming at its best.

The only reason I don't like this, and I know this is just me being pedantic, is the amount of returns. I don't know if there's something processing wise, to be gained from having multiple, as opposed to having just one that returns a variable and the manipulating the variable in stead.

I would love to learn about the various ways, and benefits of each.
I know it's somewhat tied to the term Cyclomatic Complexity, and the measure that "The more returns, the more 'complex' the code. and the simpler the better."

What are your takes on this?