31–40 of 66 posts
What Node.js taught me is that JavaScript is language like any other. It has good parts, it has quirks and you have to know what are its strenghts and what are its weaknesses to use it properly. And you can say that about any other language.
Lots of comments here, and on the blog, essentially stating "It's not Javascript, it's that you forgot to [lint|test|format|.+]" There are tools to make up for these language deficiencies, but our attitude to those bitten by the language deficiencies it's truly unfortunate. Even Python, everyone's second favorite dead horse for dynamically typed language problems, would throw an error here.
"It's not the language's fault; it's your fault for not using all the tools and best practices that make the language tolerable!"
That, to me, sounds like the language has some deficiencies.
Optional semicolons is my biggest hate with Javascript --- combined with expression statements silently discarding their result, it makes this kind of mistake far too easy to make. Personally I've never understood with Javascript strict mode doesn't make semicolons mandatory.
It's not an excuse, of course.
Earlier quoted context omitted.
Is a function longer than 10 lines considered a problem by JavaScript analysis tools (or their users)? Surely you jest?
No, by Ruby analysis tools like Rubocop. For my Javascript I use CoffeeScript, and I rarely go over 10 lines for a function. Javascript obviously is a bit weird in this because many Javascript programmers wrap whole prototypes in closures. If your function is over 10 lines, it's probably bad, just look at your functions. Every 10+ line function I've ever written was only that long because of laziness and reducing the…
>I recently wrote some code for Class::Sniff which would detect "long methods" and report them as a code smell. I even wrote a blog post about how I did this (quelle surprise, eh?). That's when Ben Tilly asked an embarrassingly obvious question: how do I know that long methods are a code smell?
>I threw out the usual justifications, but he wouldn't let up. He wanted information and he cited the excellent book Code Complete as a counter-argument. I got down my copy of this book and started reading "How Long Should A Routine Be" (page 175, second edition). The author, Steve McConnell, argues that routines should not be longer than 200 lines. Holy crud! That's waaaaaay to long. If a routine is longer than about 20 or 30 lines, I reckon it's time to break it up.
>Regrettably, McConnell has the cheek to cite six separate studies, all of which found that longer routines were not only not correlated with a greater defect rate, but were also often cheaper to develop and easier to comprehend. As a result, the latest version of Class::Sniff on github now documents that longer routines may not be a code smell after all. Ben was right. I was wrong.
Just as when someone says: Typescript would not allow this, or that. Or use strict mode would not allow that. Yes! True. They would not. But they are not JS: they are Typescript, or JS strict mode, or...
There was an article here a while back about "tabooing your words"[0], and I think it applies very well here. Instead of talking about just "Javascript", let's try to not mention it. Say "Ecmascript 5 without any tooling," or "ES 6 with 6to5", or "Ecmascript 5 with a linter", or "Ecmascript 5 in strict mode with a linter."
Suddenly, you will find that everyone in this thread agrees: "Ecmascript 5 in non-strict mode, without special tooling" is a shitty language for humans to write because mistakes so easily go unnoticed. And humans make mistakes.
And if you do use linting, or whatever, no need to feel offended: we're not talking about that language!
In essence, saying "the linter would have caught this" is like saying "Typescript doesn't allow that". It's completely true, but it's a different language.
The author was not talking about "Javscript", but about "Ecmascript 5 in strict mode without tooling." And I think we can all agree: that language is problematic.
[0] https://news.ycombinator.com/item?id=6855568
EDIT: Author was talking about strict mode. Still problematic.
Earlier quoted context omitted.
No, by Ruby analysis tools like Rubocop. For my Javascript I use CoffeeScript, and I rarely go over 10 lines for a function. Javascript obviously is a bit weird in this because many Javascript programmers wrap whole prototypes in closures. If your function is over 10 lines, it's probably bad, just look at your functions. Every 10+ line function I've ever written was only that long because of laziness and reducing the…
I remember Code Complete giving a different recommendation, googled and found this: http://stackoverflow.com/a/670039 >I recently wrote some code for Class::Sniff which would detect "long methods" and report them as a code smell. I even wrote a blog post about how I did this (quelle surprise, eh?). That's when Ben Tilly asked an embarrassingly obvious question: how do I know that long methods are a code smell? >I thr…
Of course I wouldn't have written that blog-article then, and wouldn't have gotten onto the HN homepage... Oh, well... :)
Earlier quoted context omitted.
Is a function longer than 10 lines considered a problem by JavaScript analysis tools (or their users)? Surely you jest?
That's not a function longer than ten lines. That's a single expression longer than ten lines.
If the first couple of results were numbers or booleans, they would be summed:
> true + 10 + " result"
11 result
> [true,10," result"].join('')
true10 resultThe "JSlint catches this" argument is valid, but not to defend JS. When you say: "with a linter this doesn't happen," you're defending (Javascript + linter), not Javascript. Just as when someone says: Typescript would not allow this, or that. Or use strict mode would not allow that. Yes! True. They would not. But they are not JS: they are Typescript, or JS strict mode, or... There was an article here a while back abo…
It was in strict mode. It allows that.