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,
srcX, srcY, srcWidth, srcHeight,
dstX, dstY, dstWidth, dstHeight,
const normals = [-1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1];
const positions = [
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.
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.
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)
if (null == customer.id)
However - working with client B
if (null == customer.name)
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.
def some_function(arg1, arg2, arg3):
temp=arg1*arg2;temp=numpy.some_function(temp, arg3);return temp
I was almost useless work. Worse yet, we couldn't fire him because we were mandated by higher ups to keep him in the team for the duration of the internship he had to do to comply with some scholarship requirement with an institution we're related.
Again, the style guide we've written works for our team and the #1 rule is: code must be clear. There are a few other rules (variables and functions are snake_case, classes are CamelCase and so on), but those are derived from #1 and habits/experience the team has developed over years of work.
I also understand they situation you say: putting style/beauty/the linters as an objective and forgetting about what the code has to do in the first place. Can't really help you there, I am aware (and happy) that my team and I are in sync.
No worrying about formatting code as I type, no worrying about checking style on PRs... definitely worth the trade offs for me, I enable it on every project I work on now.
Why would... you want that? You're trading minimal syntactic noise for possible ambiguity errors. You don't really gain anything.
† (if you follow these rules I memorized to show off how smart I am).
The theme was primarily made for me, but I published it because others might find the idea useful.
And the whole point here is that tooling eslint/prettier prevents bugs.
Prettier will turn this:
const x = foo()
[1, 2, 3].forEach(...)
const x = foo()[1, 2, 3].forEach(...)
Btw, if you decide to avoid semicolons, one of the only rules you need to know is to prefix any line with a semicolon if it starts with "[(.
Frankly, I die inside every time I work with a semicolon codebase and have to move a semicolon just to chain onto:
And seeing as how we're on an ESLint thread... there are tools for that. ;)
Asking because to me personally it seems that it's easy to create a new TypeScript app from a template with zero configuration, and then it just works. Perhaps I'd need to spend 5 minutes to write the type for the API responses or some other basic stuff like that.
// eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary.
// Here's a description about why this configuration is necessary.
// eslint-disable-next-line no-console
1. Sometimes there's already a comment on the preceding line commenting the logic, and the new comment explaining ESLint would have to go awkwardly in-between.
2. Sometimes it's just complicated to word the comment if it can't be on the same line.
3. Sometimes eslint-disable-line is in a place where it would be ugly to have a comment above. Here are two examples from my current project, both from cases where the disable is right after a closing curly brace:
} as any // eslint-disable-line @typescript-eslint/no-explicit-any
}, [map]); // eslint-disable-line react-hooks/exhaustive-deps
Feature request #1: https://github.com/eslint/eslint/issues/11298
Feature request #2: https://github.com/eslint/eslint/issues/11806
Next up: an ESLint rule that makes the comment obligatory for disable directives.
Looking at one suppression in one place it doesn't make a big difference.
It will help a lot with whole-project search results, though, if you're trying to e.g. fix all the places you had to suppress X because of Y.
Haven't ran into too many issues within the last 8 months or so. Only in Spring 2019 was it bad IME.
I switched to jshint and have lived a much happier life.
> The primary reason ESLint was created was to allow developers to create their own linting rules. ESLint is designed to have all rules completely pluggable.
> Every rule... Can be turned off or on (nothing can be deemed "too important to turn off")
> Rules are "agenda free" - ESLint does not promote any particular coding style
Is it the eslint that's opinionated, of the rules config that you were using? Or the maintainers of the rules in the github repo? (or is this sarcasm :)
ESLint is not opinionated.
> ESLint would not let us adjust settings to accept some of our normal convection's and company code style guidelines.
> I switched to jshint and have lived a much happier life.
JSHint is more opinionated and less configurable than ESLint.
I have to ask, but uh...did you maybe get the names of the tools mixed up?
Sometimes I can't use another tool because another dev has snuck the change into the repo. I can't be privy to every change at a large company. I also can and will continue to be bothered by the existence of prettier because of this. Sometimes I like being bothered. It let's me know what kind of crap to avoid in the wild. If this explain bothers you, you should consider other contexts where problems may apply.
~ λ cd /tmp/js
/tmp/js λ npm init -y & npm i eslint babel
/tmp/js λ du -h node_modules
I should have been more precise in my first comment though.
This was a few months ago, but tslint takes a few seconds on one of our larger code bases. However ESLint with the typescript plugin would take up to a minute+, and seemed to make webstorm struggle with the eslint integration.
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.
Please use that rule. So many bugs in the JS world is because of dangling promises.
But, I agree with your point, that rule can catch a lot of bugs.
You're mixing so many different things right now.
Yes, and I subscribe to the parent's sentiment: this rule is essential
That's the name!
Not now, but it's planned to be starting with the next major version. They are holding off until then since changing the default rules is considered a breaking change.
HN should automatically detect this and let me know :D
Unfortunately I think the comment is too old to edit.
That's on the list!
I've reopened the comment for editing if you still want to.