Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESLint 7.0

eslint.org

Post reply on HN
Print view View original

81–90 of 93 posts

Re: ESLint 7.0

#81

Post by hn_throwaway_99 »

gfxgirl wrote: post #64
vorpalhex wrote: post #18

Earlier quoted context omitted.

I also recommend `prettier`. It can be configured to obey eslint and will reformat your code on the fly to fit standards so you can spend less time fighting spacing and more time just writing code. While `eslint --fix` is a thing, prettier parses the underlying AST to do it's transformations and it's a very impressive tool.

It should be renamed 'uglier' or 'obfusticate' const normals = [ -1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1, ]; const positions = [ -1, -1, 0, 1, -1, 0, -1, -1, 0, -1, -1, 0, 1, -1, 0, 1, 1, 0, ] ctx.drawImage( image, srcX, srcY, srcWidth, srcHeight, dstX, dstY, dstWidth, dstHeight, ) becomes const normals = [-1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1]; const positions = [ -1, -1…

I used to feel as you do, which is basically "What about the special cases!" But then I realized that it was much preferred and easier to have consistent styling automatically enforced everywhere. For the rare times I really don't like it, I can just add an ignore prettier comment.

The one thing I'll give to you is the handling of arrays. There is an open issue to treat array literals the same as object literals in that newlines between elements will be respected and not automatically compressed onto a single line if the whole line is less than max-width. After about a half year of usage that's the only default I really don't like.

Re: ESLint 7.0

#82

Post by soulofmischief »

traes wrote: post #53
haolez wrote: post #3

I didn't like programming in JavaScript so much because I think the syntax makes it a little harder to read than necessary. However, I confess that after adopting ESLint in my workflow, things have improved considerably. I can ask it to warn me on unused stuff, to enforce the lack of semicolons, to format and indent my code correctly on save... it's a very useful tool. If you have something against JavaScript in gene…

> to enforce the lack of semicolons Why would... you want that? You're trading minimal syntactic noise for possible ambiguity errors. You don't really gain anything.

After every single line is not minimal. It's redundant.

In 30 minutes you can learn to recognize and practice handling all of the cases where a semicolon would be necessary. There is no ambiguity because the rules for statement termination are rigid. If you find it hard to navigate with only explicit semicolons, then you should brush up on your JavaScript knowledge.

And seeing as how we're on an ESLint thread... there are tools for that. ;)

Re: ESLint 7.0

#83

Post by tomduncalf »

_virtu wrote: post #44
tomduncalf wrote: post #40

Earlier quoted context omitted.

Yeah that’s what I mean about PRs - such a time saver to not discuss trivial code style issues and be able to just focus on the code itself!

I'll never forget getting our team of 90+ devs to move to prettier because of this argument and then having team members proceed to strong arm me to change the configs to things that they preferred six months after we made the move and we had adopted it across over 10 different repos. Talk about counter to the whole point of using such a wonderful tool.

That must have been frustrating - I do feel like perhaps they made a mistake adding configuration to prettier at all! But especially for matters of preference such as single vs double quotes where ultimately it makes very little difference. Luckily my team are happy with the defaults + slightly longer line length

Re: ESLint 7.0

#84

Post by dwrodri »

I know the whole "there are two types of programming languages" Stroustrup quote applies to JS just as much as it does to C++, but can anyone comment on whether JS was hated as much as it was back when this second generation of browsers was being built? As someone who went straight into research and low-level work, I don't touch JS very often, but it seems to me as though the Web is in this arranged marriage it doesn't like, but refuses to leave because of the inconvenience.

I feel like in some regards, we have seen generational shifts in other languages. In domains where Perl, Java, and C++ used to dominate, we now have Go, Rust, and Python.

Absolutely worth noting that with the exception of Python, there are probably still vastly more lines of C++/Java code running in production than Go/Rust. I kind of don't get how if JavaScript is so bad, then why do we now have things like Node?

Re: ESLint 7.0

#85

Post by vorpalhex »

gfxgirl wrote: post #64
vorpalhex wrote: post #18

Earlier quoted context omitted.

I also recommend `prettier`. It can be configured to obey eslint and will reformat your code on the fly to fit standards so you can spend less time fighting spacing and more time just writing code. While `eslint --fix` is a thing, prettier parses the underlying AST to do it's transformations and it's a very impressive tool.

It should be renamed 'uglier' or 'obfusticate' const normals = [ -1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1, ]; const positions = [ -1, -1, 0, 1, -1, 0, -1, -1, 0, -1, -1, 0, 1, -1, 0, 1, 1, 0, ] ctx.drawImage( image, srcX, srcY, srcWidth, srcHeight, dstX, dstY, dstWidth, dstHeight, ) becomes const normals = [-1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1]; const positions = [ -1, -1…

I highly recommend spending some time configuring your prettier, especially if you regularly write out matrices. It's very much preconfigured for FE heavy development which doesn't work for me either - but you can have a global root config tweaked to your preferences.

Re: ESLint 7.0

#86

Post by z3t4 »

hombre_fatal wrote: post #78
z3t4 wrote: post #30

Earlier quoted context omitted.

If you add a catch block it will be even worse, all errors inside a promise callback will then become soft errors. Only add the catch if you actually plan to handle the error.

promise.catch(console.error) is still handling the error.

That's still a soft error. Meaning the app will continue like if nothing happened. Resulting in poisonous state.

Re: ESLint 7.0

#87

Post by tracker1 »

mmgutz wrote: post #59
tracker1 wrote: post #51

Earlier quoted context omitted.

yeah, I pretty much rely on eslint and prettier across the board... I do have a couple tweaks though[1]. 1. https://gist.github.com/tracker1/e6c2befae41856da27973cf22cf...

And editorconfig

Show me where editorconfig does formatting or linting.

Re: ESLint 7.0

#88

Post by dr_zoidberg »

iandev wrote: post #66
gfxgirl wrote: post #64

Earlier quoted context omitted.

It should be renamed 'uglier' or 'obfusticate' const normals = [ -1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1, ]; const positions = [ -1, -1, 0, 1, -1, 0, -1, -1, 0, -1, -1, 0, 1, -1, 0, 1, 1, 0, ] ctx.drawImage( image, srcX, srcY, srcWidth, srcHeight, dstX, dstY, dstWidth, dstHeight, ) becomes const normals = [-1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1]; const positions = [ -1, -1…

If your team consistently writes code that looks like your first example, you absolutely shouldn't use prettier. However, in my experience, your first example isn't what people regularly produce and the output is a wild improvement on a lot of things that I've seen people write.

The use of code "prettifiers" (in general) helps save effort on having a code style guide, and people following it. As you, and others have said, it depends on the project.

Clearly for projects where devs have the habit and follow a clear style, it's not necessary. However on mosy projects, you'll have the one guy who doesn't follow, or worse, the only one guy who follows the style. And so the prettifiers become absolutely necessary.

Re: ESLint 7.0

#89

Post by Latty »

dwrodri wrote: post #84

I know the whole "there are two types of programming languages" Stroustrup quote applies to JS just as much as it does to C++, but can anyone comment on whether JS was hated as much as it was back when this second generation of browsers was being built? As someone who went straight into research and low-level work, I don't touch JS very often, but it seems to me as though the Web is in this arranged marriage it doesn…

If I had to guess, I'd say Node is popular because the web has eaten the world, and if you already have a web app as the core of your development, it starts to make sense to make everything else just an extension of that, including your server so you can do things like server-side rendering.

A lot of that development seems to be TypeScript too, which helps mitigate a lot of the problems of raw JavaScript, and the structural typing makes working with JSON (something now pretty universal too) far easier than with a lot of languages.

There are a lot of things I hate about JavaScript itself, but TypeScript's type system is genuinely great.

Re: ESLint 7.0

#90

Post by secondaryditto »

dr_zoidberg wrote: post #88
iandev wrote: post #66

Earlier quoted context omitted.

If your team consistently writes code that looks like your first example, you absolutely shouldn't use prettier. However, in my experience, your first example isn't what people regularly produce and the output is a wild improvement on a lot of things that I've seen people write.

The use of code "prettifiers" (in general) helps save effort on having a code style guide, and people following it. As you, and others have said, it depends on the project. Clearly for projects where devs have the habit and follow a clear style, it's not necessary. However on mosy projects, you'll have the one guy who doesn't follow, or worse, the only one guy who follows the style. And so the prettifiers become abso…

> However on mosy projects, you'll have the one guy who doesn't follow, or worse, the only one guy who follows the style. And so the prettifiers become absolutely necessary.

I'll bite - why, exactly, is this "absolutely necessary"? The justifications for needing style guides and linters that I get is usually something like "so we don't argue about this stuff". Well... I wasn't arguing in the first place - you were. And every project will have someone who wants to add their own preference in 'because'... so regardless of what you're in, nothing is 'standard', ever.

My experiences may be somewhat outside the norm, but in the last... 18 months or so, I've worked with 3 different teams (anywhere from 3 to 20+ other people) across php, js - angular/vue/node, java and ruby. There's been more in-fighting and bike-shedding about "standards" from people who tend to be the least productive.

I can fully admit some code is, sometimes, easier to read when formatted certain ways. No one seems to ever be able to admit or acknowledge that sometimes, it's very hard for me to read in their preferred style. I don't complain. I just ... get on with it.

Again, my experience may be different from others, but of the multiple folks I've dealt with in the past couple of years, the ones who were open vocal advocates about needing "standard" and forcing style/linting/etc on to projects - these people rarely ever found bugs in their own code or code from others, or spotted logical problems with the code, or, indeed, contributed tests. It's as if they equate 'code beauty' with the actual functioning of the code itself. "Hey, it looks good, I'm checking it in" - this is now reinforced with "hey, all my linting/style is passing - awesome - checking it in!"

I initially chalked this up to one person, but in my experiences, it's been a recurring trait/behaviour.

I jump between projects/contracts. I've never worked at one company on one project and one team for multiple years - the dynamics are certainly different from short term projects.

Current situation - two client projects.

Client A - fanatical about 'null==' because there was some bad assignment by mistake issue a few years back. This is a hard rule, and code will be blocked if you commit

    if (customer.id == null)
has to be

    if (null == customer.id)
I understand the value, but ... tests help catch those issues as well. But... my habit over the last 6 months has been to default to that.

However - working with client B

    if (null == customer.name)
"this is confusing - none of the other code uses this style, it's hard to read, stop doing it".

So, in the same week (sometimes, the same day), I have multiple competing styles in my head, and regardless of what I do, I have a productivity loss because something has to check/correct and I have to wait, or I have to recommit and re-push stuff because something was 'wrong' to someone. When you switch between "styles" enough, it begins to seem a bit cargo-cultish, to my eyes.

Post reply on HN