[gfxgirl]

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.

[hn_throwaway_99]

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.

[iandev]

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.

[dr_zoidberg]

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.

[secondaryditto]

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

[dr_zoidberg]

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.

[hombre_fatal]

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

[vips7L]

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

[vorpalhex]

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.