Consider using more normal casing rules

[domenic]

Since I'm filing issues with suggested breaking changes anyway (#55), I thought I'd file this one as well...

It's very confusing for me that this library doesn't follow the usual camelcasing rules of uppercasing every word after the first. (Seen e.g. in standard APIs like Uint16Array.) Instead, it seems to lowercase words if they follow a number. This has led to a number of runtime failures for me and my LLMs as we try to write code against the library.

It would be nice if this library updated its method names, e.g. fromBase32hex -> fromBase32Hex, windows1252fromString -> windows1252FromString, etc.

[ChALkeR]

This can be done in a non-breaking way (aliases + typedoc-deprecations), but there was some logic behind that, which I need to recheck

[ChALkeR]

All of the methods follow the same pattern: letters directly after digits are not capitalized.

There are a lot of digits in the middle of function names, and capitalizing letters after those hurts readability for humans.
Even in the examples above: in fromBase32Hex / windows1252FromString the first letter after digits reads as a contiuation of the digits because of the same height and being valid hex in some cases.

Case switching in camelcasing is needed for parts separation, and a lowercase letter after digits better visually separates the part from digits than an uppercase letter.

LLMs should be using .d.ts?

[domenic]

capitalizing letters after those hurts readability for humans.

I don't think that's true... I think breaking from convention hurts readability more. It certainly makes me visually stumble as I end up having to internalize the rules which are unique to this library over the ones that the rest of the JS ecosystem uses.

LLMs should be using .d.ts?

A lot of the times they just assume that if one method exists, the others must as well. They'll figure it out and go consult the .d.ts after they get errors, but it's extra tokens wasted.