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.
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.
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.
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.
2 replies →
This will give
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();
2 replies →
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.