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,
      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
    );

Those are less pretty and useful info is lost.

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.

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.

> 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.

I understand your experience, and based on mine I can tell you this: I absolutely hated the time I had an intern to whom I taught python, showed him the guide style and he insisted in writing things like this:

    def some_function(arg1, arg2, arg3):
        temp=arg1*arg2;temp=numpy.some_function(temp, arg3);return temp

Those innecessary oneliners where a mess. And the arguments names? Not shortening for the example, they guy did that. In the end whatever work he did, we had to dedicate one of our programmers who had an idea of what those functions where supposed to do to "translate them back".

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.

You can tell prettier to ignore the next node: https://prettier.io/docs/en/ignore.html

While I agree about the arrays. I much prefer the function call.

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.

Yeah, prettier rocks. I was skeptical for a long time and if I’m honest and think about it I still don’t like some of the formatting choices it makes, but I don’t notice because of how fluid and pleasant it makes writing code. As an aside, often the “workarounds” result in clearer code, e.g. long formulas getting split up weirdly leads to me splitting stages of the calculation into named variables, which actually reads much better when I return to it months later.

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.

And if you are working in a team it makes those arguments about styling moot. One of the best aspects of JavaScript.

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

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.

TypeScript. ( + ESLint, + Prettier ). It has made writing JavaScript tolerable. Classes as you expect them. With proper editor support, you get real errors, and the whole thing starts to feel more like writing code in python. It is no python, but at least it feels significantly less foreign. Its very progressive in the sense that regular JavaScript is valid TypeScript, and everything else is just a cherry on top. And it is easy to include the typing outside of the source file, so many libraries not written at all in TypeScript have typing support built in (likely by simple PRs from the community)

> 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.

This is like asking "vim or emacs". You'll never change anyone's mind on the matter, but you'll get the same old arguments from ~ten years ago [0] about how this is both "very simple†" and "pointless mental overhead" at the same time.

† (if you follow these rules I memorized to show off how smart I am).

---

[0]: https://github.com/twbs/bootstrap/issues/3057

In combination with other linting rules to catch reckless conditionals and multiline returns, it is absolutely safe to enforce no semicolons. And the visual noise is, at least to my eyes, a significant impact.

If visual noise is an issue, I made a VSCode theme specifically for muting things like quotes and semicolons, that way I don't have to choose between explicit semicolons and reduced visual clutter: https://marketplace.visualstudio.com/items?itemName=wildpeak...

The theme was primarily made for me, but I published it because others might find the idea useful.

You need to know when semicolons are necessary whether you use them or not.

And the whole point here is that tooling eslint/prettier prevents bugs.

Prettier will turn this:

    const x = foo()
    [1, 2, 3].forEach(...)

into this:

    const x = foo()[1, 2, 3].forEach(...)

Which makes the problem pretty obvious.

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 "[(.

Introducing any mental overhead to eliminate a single character per line at most seems a tad ridiculous.

I haven't used semicolons for at least 5 years. Let's not overstate the "overhead", which I would say is zero. Especially in this comment thread where we just established the tooling handles it for you.

Frankly, I die inside every time I work with a semicolon codebase and have to move a semicolon just to chain onto:

    promise
      .then()
      .catch();
    + .then();

    foo
      .bar()
      .baz();
    + .qux();

You are making the common developer/HNer mistake of overvaluing familiarity and overestimating how hard anything slightly unfamiliar must be.

I challenge you to try it the next time you write some Javascript. Don't use semis and remember the one rule I taught you.

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. ;)

You can do most of that without ESLint for any programming language with an IDE. Speaking about jetbrains intellij/pycharm from my own experience.

The IDEs will sometimes use their in-house solution, and sometimes integrate one of these external tools that focus on doing just one thing very well. My setup is VSCode + ESLint when dealing with JavaScript.

The point of these tools is that the configuration is specified in the project, and works regardless of the developer's workflow.

TypeScript.

My use of JavaScript is mainly for small code bases. The gains of TypeScript are less relevant in this scenario over the bureaucracy that it brings to the game.

What does this bureaucracy look like?

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.