These 17 lines had 100% test coverage and were used by a stupidly large amount of people (read: battle tested), why not use it?
As is pointed out elsewhere in this thread, echo.c is roughly the same size, does that mean it's not a worthy program?
These 17 lines had 100% test coverage and were used by a stupidly large amount of people (read: battle tested), why not use it?
As is pointed out elsewhere in this thread, echo.c is roughly the same size, does that mean it's not a worthy program?
The fact that in JS land it would be it's a standalone module means you get more choice in what you need (no need to pull down 100 programs if you only need 1 or 2).
But to be fair this would have the same outcome if left-pad were part of a library that included another 50+ libs (that he also wrote and published, and subsequently un-published today).
Choice can be a bad thing too - when there are 10 different modules for doing a moderately complex thing, you have to figure out which one is best for your project, and whether it's still actively maintained, bugs are fixed, how do they feel about making breaking changes, etc.
Not necessarily, take a look at lodash and friends. There is nothing stopping bundling of tiny modules into big "libraries" to be used.
As for the rest, you need to do that validation anyway. But if it were bundled in a large library there is MUCH more code that you need to review.
with something like the module "left-pad", it's a no brainer to use the library. I know that it's under an EXTREMELY open license, the code is really small, and by vendoring your dependencies (you are vendoring your dependencies right?) this whole issue would have been a 5-10 minute fix that only needed to be done when you want to upgrade your dependencies next time.
And that doesn't remove the need for a library like this (or your own implementation) for a long time because you can't rely on a brand new release to be available for everyone.
I've seen several "one liners" in this thread already, and most of them either blow up when something that's not a string is passed in (regardless of how you view strict typing, js doesn't have it and this shouldn't happen), or are extremely slow comparatively (most of them creating and destroying an array every time they are called).
Plus this has 100% test coverage (even as trivial as it is, it still counts), and is "battle tested" (something like 2.5 million installs per month counts for something).
Sorry, but i'll stick to left-pad vs 20-seconds of thought one-liner.
How's this:
function leftpad (str, len, ch) {
ch = (len -= str.length) <= 0 ? '' : !ch && ch !== 0 ? ' ' : String(ch);
while (--len > 0) ch += ch[0];
return ch + String(str);
}
No local variables, less manipulation of the input string, the string grows at the tail which is more efficient, and the code is much shorter.(With a bit of work you can use the longer ch string that is built to reduce the number of string appends even more by appending multiple characters at once. Although probably not worth it for this function.)
I strongly disagree. My code has no magic initializers (the -1 in the original) and a simple linear code path, with no branching. It's very easy to read and understand.
The ternary operator at the top is simply read from left to right, it's not complicated.
> If your goal is to minimize the amount of lines, then you succeeded.
My goal was to maximize efficiency. Often that means less lines, but that was not the overt goal. And in fact this version runs faster, and uses less memory.
> If the goal is to produce both correct and readable code, then there's room for improvement.
You think so?
Then now it's your turn - rewrite this (or the original) to make it as readable as possible. I think you will find that a: mine is more readable than the original, and b: you won't be able to (need to) change much except to lift the len initializer out of the ternary operator in the first line onto its own line.