On 07/12/2019 18:19, sebb wrote:
On Sat, 7 Dec 2019 at 17:05, Bryan Rickman <bryan.rick...@gmail.com> wrote:

I recently used the text.CaseUtils for converting to camelCase and
PascalCase. I also needed to convert to snake_case and kebab-case, and
ended up writing my own code for that (I wasn't really a big fan of other
utility options out there). Would it be well received if I submitted a PR
for adding that support to CaseUtils? If so, any recommendations on what to
include or not include?


Is there a need for kebab-case in Java?
The hyphen is not valid in Java identifiers; indeed many other languages
don't allow them either.

I'm not sure that it's worth adding snake_case either.
AFAICT it's trivial:  string.replaceAll(" ", "_")
(similarly for kebab-case)

Or is it really more complicated than that?

Seems to me that the cost outweighs the benefits in these cases.


Kebab-case is often used in configuration files. Spring Boot for instance prefers it over camelCase (although it does accept camelCase as well).

snake_case isn't as easy as that. To convert from camelCase to snake_case, you also need to replace any upper case character with an _ followed by that character in lowercase. For example, camelCase would become camel_case. There are some interesting corner cases as well, I handled a few of them myself once but probably not all. Once you have snake_case it's easy to convert to kebab-case, and vice versa (kebab.replace("-", "_") gives you snake_case; (please never use replaceAll if you simply want to replace a String literal; the first argument to replaceAll is a regex).

If this were to be implemented, I'd go for one private utility method that gets the separator character as argument, because the two are too alike to justify implementing it twice, and I'd hate calling replace("-", "_") when you're replacing something you've just built.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to