hitori.dev

In Opposition to 1TBS

For a brace style with such a pretentious name, the 1 True Brace Style has a lot of unanswered issues:

1. Horrendous comment placement

While other brace styles have natural placements for comments, 1tbs does not.

Variant 1: Why is the comment for the else block syntatically enclosed entirely by the if block?

// this is when the world blows up in 2026
if (supercomputerAI.getEndOfWorld().year() === 2026) {
  ...
// this is when the world blows up not in 2026
} else {
  ...
}

Variant 2: Why is the comment for conditional blocks the only violator of the comment-preceeding-commented-entity pattern?

if (supercomputerAI.getEndOfWorld().year() === 2026) {
  // this is when the world blows up in 2026

  // cool variable
  const money = 69420;
  ...
} else {
  // this is when the world blows up not in 2026

  // cool variable
  const money = 69420;
  ...
}

Variant 3: wtf

// this is when the world blows up in 2026
if (supercomputerAI.getEndOfWorld().year() === 2026) {
  ...
} else if (someLongConditionalThatTakesUpSpace) { // this is when the world blows up not in 2026
  // cool variable
  const money = 69420;
  ...
}

2. Obfuscation during quick visual scanning

Imagine you're 6 hours into the work day and a P0 production bug comes in with hundreds of thousands in revenue impact, and you're debugging code quickly. Which style is more obvious?

if(true === true) {
  const sit = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let dolore = 0;
  let magna = 0;
  const aliqua = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
  const enim = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let ad = 0;
  let minim = 0;
  const veniam = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
} else {
  const sit = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let dolore = 0;
  let magna = 0;
  const aliqua = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
  const enim = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let ad = 0;
  let minim = 0;
  const veniam = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
}

vs

if(true === true) {
  const sit = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let dolore = 0;
  let magna = 0;
  const aliqua = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
  const enim = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let ad = 0;
  let minim = 0;
  const veniam = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
}
else {
  const sit = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let dolore = 0;
  let magna = 0;
  const aliqua = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
  const enim = ipsum == null ? 0 : ipsum.sit;
  if (!sit || ut < 1) {
    return [];
  }
  let ad = 0;
  let minim = 0;
  const veniam = new eiusmod(labore.ut(sit / ut));
  while (dolore < sit) {
    aliqua[magna++] = consectetur(ipsum, dolore, (dolore += ut));
  }
}

Are your tired eyes going to notice a lone } without indentation when scanning quickly? From personal experience, it's already difficult enough to spot the 2-line else when scanning too fast, why make it even harder?

3. Diff clarity

  if (foo) {
    do();
    something();
+ } else if (condition) {
+   do();
+   something();
+   else();
  } else {
    fizzbuzz();
  }

vs

  if (foo) {
    bar();
  }
+ else if (condition) {
+   do();
+   something();
+   else();
+ }
  else {
    boo();
  }

The same people who add commas to the last multiline array item or object property for the sake of clean diffs, despite it being syntactically incorrect as js is designed, are often times the same people embracing 1tbs; I have no idea why. My guess is, these people don't want to think for themselves and they just accept whatever Prettier decided to implement, which is fine in itself, but it also disqualifies them from judging formatting choices when they haven't spent the effort to understand the reasoning behind them. Also, Prettier prioritizes form over function, terseness over clarity, which doesn't make its choices automatically correct. If anything, it makes their choices incorrect in corporate settings.

I don't understand why people value terseness outside of the idiotic notion of "I can read this and you can't". You can be as terse as you want in a codebase that only you will touch, but as soon as another dev is involved, cognitive difficulty should be minimized and code style structured in a way that clearly conveys intent and prevents mistakes.

#code_formatting