> so what harm is there in one codepoint no one will ever need?

Fonts bloat (do you want a font with 1 million characters in it ? I don’t. Do you want to have to install 1000 fonts having 1000 characters each to be sure to cover all the Unicode table ? I don't).

Lots of issues for everyday programmers (how do you handle weird unicode characters in your validation code ?) potentially leading to security issues (bypassing validation rules by close-but-different characters, phishing…)

  check()
    .then(result => {
      if (result) {
         // set state to finished
      }
      check()
        .then(result => {
          if (result) {
              // set state to finished
          }
          check()
            .then(result => {
              if (result) {
                 // set state to finished
              }
              check()
                .then(result => {
                  if (result) {
                    // set state to finished
                  }
                  check()
                    .then(result => {
                      if (result) {
                         // set state to finished
                      }

                      // set state to not done
                    })
                    .catch(error =>  // set state to failed);
                })
                .catch(error =>  // set state to failed);
            })
            .catch(error =>  // set state to failed);
        })
        .catch(error =>  // set state to failed);
    })
    .catch(error =>  // set state to failed);

For the love of everything that’s sacred, please don’t do this. The strength of promises is that they can free us from that exact kind of callback hell, and they do that by being chainable.

  const resultOrNull = await Promise.resolve(null).
       then(result => result || check()).
       then(result => result || check()).
       then(result => result || check()).
       then(result => result || check()).
       then(result => result || check()).
       catch(error => null);

Calling .then/.catch inside of a .then/.catch is a huge red flag. Almost always, you want to return the promise and chain instead.

You’re right of course.

But you having the “.” dot one line above made my spine tingle in all the wrong ways. Not that it matters.

The dot one line above is the better style. Change my mind.

Pasting

  check()
    .then()

in node REPL gives :

  > check()
  undefined
  > .then()
  Invalid REPL keyword

Pasting

  check().
    then()

Gives the expected result.

More generally, Javascript rules about whether a newline constitutes the end of a statement or not are pretty confusing (at least for me), so I prefer using a form that makes it explicit when a statement continues on the next line.

I see your perspective but a function call on a line with just the two spaces looks like poor formatting. At a glance it doesn't appear connected to the previous line until I look at the end of that previous line.

My statements end in ; Lines that begin with something other than const or let are likely function calls. If it starts with . then it is connected with the previous line and the statement isn't complete.

But if you're consistent in that style that is all important. Better consistent style in a project than one style over another.

I go back and forth on this, I can't make up my own mind let alone change anyone else's!

In any case, I used to do what you do – for pretty much the same reasons – but then I've gone back to starting lines with dot (and ?, ||, &&, and other usual suspects) because I parse code left-to-right, so the presence of such a character tells me that I need to look at the preceding line(s) to get the full picture, and it doesn't so much matter if it makes things paste-friendlier. Without the dot, I've found myself move things around that shouldn't be moved around for example:

    check().
      // Insert stuff here and things break, the lack of dot on the following line had me fooled
      then()

I have no good answers for this, and like I said I go back and forth on this – sometimes in the same file even! I think generally I don't particularly like splitting a statement over multiple line's, but at the same time I like too keep a hard limit of the number of characters I can put on each line. First world programming problem for sure.

> a form that makes it explicit when a statement continues on the next line

I prefer to know that a line is dependent on the previous by having all the dots, pipes, etc on a new line. So I skim the first few characters of every line to see what's happening.

An argument not mentioned here is that having the operator on the new line results in cleaner diffs, as only one line changed. However, I don't care for that and am scared of trailing commas too.

Came here to comment on that example as well. I started panicking that someone might actually do that.

This is because of tutorials like this that it took me so long to understand promises .

> 3. People star it

> 4. It has traction ie >10k downloads preferably >50k

Why ? Your home-made code probably don't check those boxes.

Because an Unmaintained library is worse than one you write yourself because bugs are much harder to understand and fix.

You imply that you're still going to understand your code one year later. While this is a favorite fantasy of all programmers, it's usually false. Also, if you're in a team, the person running into the bug is likely not you, so it's foreign code for them anyway.

I was being brief because I was leaving work so I’ll expand a bit.

An unmaintained library is usually more difficult to fix because fixes are no longer committed back or released. At that point you can choose to vendor and maintain your own copy, or replace it with something else. And at either of those points you’re no longer in context.

My point wasn’t really geared at debugging a piece of code. A library, my own, or a coworkers are roughly comparable. The cost to fix is a lot higher in a library though.

It’s not a universal rule, despite the way I originally phrased it.

I think there is also certain negative selection bias in the sense that people are more likely to stop maintaining libraries that were badly designed / problematic to begin with. That's why I tend to be more sceptical than average when it comes to "orphaned" projects.

I've had many a struggle with this.

On the flip side, I have found libraries that are unmaintained and are pleasant enough to understand. I've forked those and used them, happy that:

1. I can quickly fix any bugs that I face

2. Someone else can make use of my maintenance.

I agree with 3, not necessarily 4.

The amount of people who uses a product does not determine is quality.

However stars can determine to an extend whether it's a project worth looking at or not.

My home-made code will probably just do the specific thing I need it to do, and not all of the other things the library has been generically designed for.