Camel case to snake case in Swift

SnakeCase.swift

extension String {
  
  func snakeCased() -> String? {
    let pattern = "([a-z0-9])([A-Z])"

    let regex = try? NSRegularExpression(pattern: pattern, options: [])
    let range = NSRange(location: 0, length: count)
    return regex?.stringByReplacingMatches(in: self, options: [], range: range, withTemplate: "$1_$2").lowercased()
  }
}

@yoni-placer this is totally subjective. It's all up to what coding standard you set for yourself. If I'm writing a hobby project, I'd totally go with whatever String extension to make my life easier. However, if I'm working on a project with reusability in mind, I'd consider some scenarios and evaluate the technical approach.

Let's say I'm writing a shared framework that's used across multiple projects. I want flattenCamalCase function implemented somewhere in my framework. If I would put it in a extension String, what if one of my downstream projects uses another framework which also has a function called flattenCamalCase in its own string extension, and both implementation are producing different results, and in one of the files of my downstream project, both frameworks need to be imported?

It sounds like I'm describing an impossible use case, but to be honest, if every framework was trying to put these "helper" functions inside string extensions, you would see a lot of namespace conflicts. The solution is quite simple though: don't do this in a reusable components. Instead, put it under MyFramework.StringUtility.flattenCamalCase as I described, so it's under a specific namespace.

Another problem is dependency management. I used to be a big fan of system class extension myself, as I just needed the write the minimum lines of code. But now when I think about it, I can't justify the fact that just to save a function parameter (self in extension, first parameter in a utility class/struct/enum), I need to make flattenCamalCase global. When you said private, I assume you didn't mean the technical term of private, as your string extension is very likely to be internal. And by doing that, you care making the whole function flattenCamalCase global across your whole project, which is as bad as using global functions and variables. Again, if it's a hobby project I wouldn't pay too much attention about dependency injection, but for a commercial project, I can't imagine a 5 or 10 developers team manage a codebase without some sort of DI.

I'm writing all these not just to answer your question. In the end, it's personal preference and is totally subjective. But if you really care about SOLID principles, which by the way are pretty "solid", this kind of discussions are quite helpful to clear up our minds. So always agree to disagree :)

just use fileprivate extension

My own take on the thing:

https://gist.github.com/CanTheAlmighty/18b443a09ebe56c3cf78bc4785438cf8