I know dark mode is all the rage. A must-have for the trend-sensitive software developer. However, the reason to have dark mode is to save people’s eyes in dark rooms… not blast them to pieces.

Take a look at Microsoft Office’s dark mode fail in a dark room, I dare you:

Of course, dark mode done right will have its issues as well… Try to pick out the orange colored comment in Scrivener’s dark mode… if you can:

Yeah, no. Those aren’t the names of the colors 😀 and it’s easy to pick the right one when you have the others for contrast, but wait till you open a document with comments in one color… is it yellow, orange, red? Ummm…

But at least Scrivener won’t leave white spots dancing in front of your eyes for the rest of the evening… so that’s always something…

I for one have learned not to use Mac OS’s Mail app to send customer mail when in dark mode. Those CCed names are pretty much hidden and all of a sudden internal e-mails become external and you find yourself wishing you’d been better at keeping your promise to never say (or write) anything about someone you wouldn’t say to them.

This bug exists in all text editors I tried so far, with the exception of iWorks Pages… (they have their own set of issues anyway…)

To recreate the bug:

1. Type text in the text editor really fast. You may even type random text if you’re not such a fast typer…
2. Immediately after, start deleting with backspace
3. Still moving quickly, press ctrl-Z (or command-Z on a Mac) for undo
4. You thought the editor would undo your deletes, right? Hah!

I’ve been kicked by this nasty thing so many times. I type something. ADHD kicks in and I change my mind half way through, starts deleting, changes my mind again and presses cmd-Z. And it undoes everything instead of just the deletes.

Word does this, Scrivner does this… every simple text editor does… apparently 99% of text editor users does the index finger waltz?

Consider the following singleton:

public enum MyVeryImportantSingleton {
  INSTANCE;

  private String a;
  private String b;

  public void set(String a, String b) {
    this.a = Objects.requireNonNull(a);
    this.b = Objects.requireNonNull(b);
  }
}

If it would be called in the following manner:

try {
  MyVeryImportantSingleton.INSTANCE
    .set("Hello world", null);
}
catch (Throwable t) {
  ...all sorts of recovery operations
  ...leaving the system running
}

MyVeryImportantSingleton‘s a-field is set, but the b-field is left in its previous state. This, of course, could turn into really bad news.

The right way to implement set() would be:

public void set(String a, String b) {
Objects.requireNonNull(a);
Objects.requireNonNull(b);
this.a = a;
this.b = b;
}

This is also a great praxis for all form of input error checking. It should first be finished, and then the object state can be updated once all input is ok.

You never know when your method will be called from inside a catch-block by a programmer that, incorrectly assumes the object state is okay even if an exception was thrown.