WRONG. Typical junior developer mistake. Even if we disregard trivial problems such as non-letter input or empty input, this will only work with English and a few other languages. This will TOTALLY fail with e.g. Turkish input (I ı vs İ i).

Not really. (string[0] == string[0].toUpperCase() && string[0] != string[0].toLowerCase()) is the correct way to approach this problem. If toUpperCase() and toLowerCase() don't handle Turkish letters, then that's a BUG in those methods, which should be reported and someone should freaking take responsibility for them and fix them.

Adding another module with a method does not fix the original problem, it just creates more problems for other people to solve.

> var isCapital function(s) { return s[0] === s[0].toUpperCase(); };

> isCapital("שלום");

true

> isCapital("1");

true

> isCapital('\uD83D\uDE00'); // Smiling emoji

true

> isCapital(\u279B); // Right-facing arrow

true

> isCapital("\u061Casd"); //Bidirectional control character

true

> isCapital(" ");

true

If "true" is not a valid answer, what would've been one? Similar code in C# returns the same. E.g. Console.WriteLine("שלום".ToUpperInvariant()=="שלום") returns true.

Hebrew doesn't have upper and lower case, so the question "is this hebrew character capital" is meaningless. So, the function in question should not return just a boolean value; it should have a way to return a third option. (Whether it's nil, a C-style return code, an exception, an enum or something else is irrelevant here.)

Actually, it just means that if you're wondering "if this word starts with a capital", you're asking a wrong question. Instead, you should be asking "if this word is a valid generic name", or "is this word a start of a new sentence", and implement these semantic queries in a language-specific way.

You have final-forms in Hebrew, although probably not at the same level of support for checking as you'd get with a script like Arabic.

That's true, but I don't think that sofits should be viewed as capital/not-capital letters: they're not semantically altering the meaning of the word in wider context, like capital letters do.

This will give

  startsWithCapitalLetter("!") == true

which is not what you want.

TIL 1 is a capital letter.

string[0] === string[0].toUpperCase() && string[0].toUpperCase() != string[0].toLowerCase();

typeof string == "string" && string.length && string[0] == string[0].toUpperCase() && string[0].toUpperCase() != string[0].toLowerCase();

Man, Javascript is AWESOME.

/\p{Lt}/.test(str) would be much more compact, but Unicode properties still aren't available in Javascript regular expressions. It doesn't look like they will be anytime soon. I guess they have some staging system and it's still at stage 0 (https://github.com/tc39/ecma262/blob/master/stage0.md), grouped with lookbehind assertions, named captures, and mode modifiers.

Not that I agree with micro modules (I would rather see a set of js core libs), but your code fails with empty strings.

That code fails in a whole host of cases, kind of proving that sometimes trivial "just one line" functions aren't actual that trivial to get right.

edit: fortunately there's an npm modules you can included to fix it...

Maybe F1axs knows that at this particular spot the string will never be empty? There are two philosophies in libraries; one is to check for every possible error in the lib function, the other is to state the pre-conditions in the documentation.

> Not that I agree with micro modules (I would rather see a set of js core libs)

Why not both? If you just want one part of a module, you can just import the dependency directly, if you want a whole core lib, you can do that.

Some people really like underscore and import that. I use ES6/7 functions for the most part, but underscore has some useful things I can import on their own.

string[0] isn't necessarily one code point.