nested if, else if, switch文を全て禁止するコーディング規約

「if 文のネストを else if も含めて一切禁止する」のコーディングルールを数年運用してまして。実装で困るメンバーはなく、何の不都合もないってのが分かりましたでござる。

複雑なコードがプルリクエストに含まれないメリットは大きく、導入しない理由は存在しませぬ。

(・ω・)＜おわかりか

code:これはいい.py

if condition:

...

code:これはダメ.py

if cond1: // cond1はok

if cond2:

ここはネストしてるのでダメですね

elif cond3:

elifなのでダメですね

---

code:これはダメ、を早期returnで置き換える.py

if cond1 and cond2:

cond2のときの処理

return

if cond3:

cond3のときの処理

return

...

ifの中でreturnするブロックをガンガン使って、後続の可能性をしぼめていくイメージ

code:js

condition ? (()=>{

// true

condition2 ? (()=>{

// true

})() : (()=>{

// false

})()

})() : (()=>{

// false

condition2 ? (()=>{

// true

})() : (()=>{

// false

})()

})()

c&&(()=>{/*T*/c2&&(()=>{/*T*/})()||(()=>{/*F*/})()})()||(()=>{/*F*/c2&&(()=>{/*T*/})()||(()=>{/*F*/})()})()

できあがり

else ifを排除したところで、全体としての複雑さは変わらないと思います。

関数単位のユニットテスト漏れが検出しやすいメリットがあるのかと思いましたが、andとかorとかも禁止ですか？

switch 文

for

while

do-while

for-in

for-of

Array#forEach()

「メソッド・関数の責務が自然に分割される」のが最大の利点でござった。

正直Xの限られた文字数だと完全な意図がよくわからないので、どこかに規約を乗せてもらえると助かります。

此れには同意ッス🤝✨

書き忘れたんですけど、let/var も禁止でした。const オンリー。

弊社のコーディング規約をまとめるだけで、読み物になりそうッスね。今のタスクが半減したらトライしてみまする。

全部mapということ？

code:script.js

[

() => { /*task_A*/ },

() => { /*task_B*/ },

() => { /*task_C*/ },

][

[

cond_A,

cond_B,

cond_C

].indexOf(true)

]?.();

一番きついのはたぶんlet禁止な気がするけど、まあfor禁止ならletも使わんか……

GPT-4o.icon

実際にこのようなルールを採用する企業は、極端なまでの関数の細分化や純粋関数型プログラミングの考え方を取り入れている可能性が高く、次のような目的があります。

実施可能な理由・メリット

関数の分割促進

if-else、switch、ループを排除することで、関数が小さく細分化され、単一責務原則（Single Responsibility Principle）を徹底できます。

ユニットテスト容易性の向上

細分化された関数ごとにテストが容易になり、バグの発見や責任の所在が明確になります。

副作用の排除

ループや変数（let/var）を禁止し、constのみ許可することで、データの状態変更（ミュータブル性）を抑え、バグや副作用を減らすことができます。

実際の運用上の難しさ・問題点

コードの冗長化

簡単な処理でも関数が多数必要になり、コードが分散し、逆に管理が複雑になる可能性があります。

開発効率の低下

慣れるまで開発スピードが著しく低下するリスクがあります。特にループ処理の代替として再帰を多用すると、可読性や性能の問題も起きやすくなります。

実行性能の問題

一般的にループよりも再帰のほうがメモリ消費やスタックオーバーフローのリスクが高いため、性能面での課題が生じる可能性があります。