結論

multi-line,consistentを採用する方針となりました

背景

const longlonglonglonglonglongVariabe = 1;
const longlonglonglonglonglongFunc = (num) => {console.log(num)}
if(a)
    longlonglonglonglonglongFunc(longlonglonglonglonglongVariabe);
longlonglonglonglonglongFunc(longlonglonglonglonglongVariabe);

ifがlonglonglonglonglonglongFunc(longlonglonglonglonglongVariabe)
どちらも中括弧でくくる必要があるのか分からない時があります。
このような時に誤って修正し、バグが起きたりします。

ルール化することで条件分岐でのバグを防ぐことができます。
そこで今回はESLintのcurlyのruleを調査したいと思います。

curlyとは

すべての制御文に一貫したブレーススタイル（中括弧のスタイル）を強制します

今回満たしたい条件

改行された単一ステートメントに中括弧を強制する
改行なし単一ステートメントでのブレーススタイルの柔軟性（中括弧を付けても付けなくてもOK）

curlyのOptionから条件を満たすものを検討する

multi-line,consistentを採用する方針となりました。
以下調査結果の概要です。

オプション	採用/不採用	強制させる条件	デメリット	メリット
all	不採用	全て	全てに適用される
multi	不採用	複数ステートメント	改行されたステートメントだと中括弧がされない
multi-line	採用	複数行	1行に複数のステートメントを書くと中括弧がされない
multi-or-nest	不採用	if、else、for、while、doの本体が複数行の時	multi-or-nestだと、1ステートメントの時に中括弧を付けられない	multi-lineと違って、改行してもしてなくても1ステートメントのみの場合は強制しないで良い
multi*,consistent	採用	multiオプションのいずれかと併用し、if,else if else chainの全てのボディを中括弧有または無に統一させるよう強制	採用（あっても良いかも）	統一できるので見やすくなる

次に解説です。

解説

all

改行してなくても中括弧を強制されてしまいます。

multi

改行なし単一ステートメントでのブレーススタイルの柔軟性が失われます。

改行された単一ステートメントに中括弧を付けるとエラーになるので不採用ですね。

multi-line

改行なし単一ステートメントでのブレーススタイルの柔軟性と改行あり単一ステートメントで中括弧を強制しているため、条件を満たしています。

multi-or-nest

改行なし単一ステートメントでのブレーススタイルの柔軟性で失われているので不採用とします。

consistent

if,else if,elseでブレーススタイルを統一できるので可読性が上がるのかなと思いました。
これはおまけなのであってもなくても大丈夫かなと思います。

最後に

これからもESLintのruleをうまく活用してコードを安全に実装し、バグが出にくいコードにしていきたいです。

参考

eslint brace-style